Exporter for Rhinoceros

[Abel]

Amazing progress! Coincidentally I just started using Rhino two days ago and I'd be very happy to do some testing.

[flatland]

Finally!i visited this page at least one time a day for an update

[nart]

Hello all-

Amazing progress! Coincidentally I just started using Rhino two days ago and I'd be very happy to do some testing.

Thanks Abel. I think it is a little early for outside testing yet...maybe after I get some kind of materials going...

Hi,

Great progress! Tell me if you want to set up a source code repository here or have an announcement or some more visibility from the main pages of the site.

Jeanphi

Jeanphi. I would like to get it a little more complete/stable before it is released into the wild.

I thought I would do a little update:

I haven't made much feature progress, as most of my time with this has been spent learning about python and how to make classes and optimize things. I also spent a lot of time learning about System.Threading.Tasks. The result is slightly more organized code and a 'task threaded' version of the geometry exporter. While it does thread the file writing process, and on average cuts the export time in about half, there is some weird stuff going on in the results that I have yet to figure out. But when it works it is pretty cool. I also had a revelation with something in rhinocommon that really streamlined the process of getting the render meshes. Now Extrusions are supported...they were not before.

In order to test the integrity of the mesh export I've been throwing some more complex scenes at it. This scene takes about 300 seconds (single thread) to export 508MB across 501 files. I don't know if that is good or bad speed-wise:

here is the rhino viewport:

I raided the Stanford scan repository (http://graphics.stanford.edu/data/3Dscanrep/ for the statue meshes..and the table was inspired by this guy's tutorial http://viscorbel.com/premium/. The statues and the grass are meshes, the rest is polysurfaces/surfaces/extrusions. All duplicates are blocks (instances).



Another scene exported in 105 seconds with 4487 files making up 202 MB. Much less complex geometry but more items. The trees are 1 block instanced.

and the rhino viewport:

and this one exported in 19.74 seconds across 350 files comprising 55.5 MB. It is not very complicated but a real world example. The spherical chair was a model from flyingarchitecture.com:

rhino viewport:

So now I am turning my attention to materials. To start off with I was going to do a basic material conversion from the rhino default mats to lux equivalents. However, for some reason, the rhino guys did not expose reflectivity or IOR parameters in rhinocommon. I'm also exploring the rdk, but it looks like what is exposed to scripters is not full access, so that is another hurdle. I have made some inquiries on their forums so we will see what they say. But overall I think it will be easier to make the materials independent of rhino and then make a basic rhino material from that. It won't be perfect GL representation but none of them are anyway. Here is a first baby step:

in rhino:

All this is, is a basic glossy material with the roughness modulated according to rhino's 'Gloss Finish' parameter, and of course color is color (although in what space I'm not sure).

That is it. If anyone has any comments I'm happy to hear them.

Thanks,

Nathan

[paco]

I don't use Rhino, but from a coding point of view i'm very impressed with your progress - nice work!

I wondered if there would be any use for a general python export routine that could be used for blender, rhino, etc - something that could handle the lux scene format side of things when given the appropriate inputs. You'd still need to get the data from rhino / blender into it but might make it faster to develop new exporters.

[Lord Crc]

I don't use Rhino, but from a coding point of view i'm very impressed with your progress - nice work!

I agree 1000%!

[nart]

Thanks for the comments guys. I attribute most of the progress to the rhinopython/common sdk; it seems very complete and easy to use, even though it is a WIP and lacks complete documentation.

I wondered if there would be any use for a general python export routine that could be used for blender, rhino, etc - something that could handle the lux scene format side of things when given the appropriate inputs. You'd still need to get the data from rhino / blender into it but might make it faster to develop new exporters.

From my experience so far, I think that updating the scene file docs and providing more actual (human-readable) examples rather than just tabular parameter data would go a long way in speeding up development. I know I have spent a lot of time trial-and-erroring, or searching through the forums, or searching through the test scenes, in order to get all the needed data to make a thing work.

[patro]

wow.... i missed all the news in this topic...
is there an alpha release planed?

[nart]

Hello all. Made a little progress on materials. It has taken a lot of experimentation and trial and error but I think I have a base down for converting basic rhino materials to lux materials. I'm only going to worry about matte, matte translucent, glossy, glossy translucent, mirror, shiny metal, glass and rough glass for this direction of conversion, and leave the advanced materials and volumes to the lux editor. I am finally getting everything from the rdk (turns out there was a bug in the python interface part), so I had color, gloss finish, reflectivity and transparency/IOR to build the materials from. We can also get to the color, transparency, and bump textures, but only UV mapping for now ('material' mapping is not yet exposed in RhinoCommon). Also, the RDK exposes the rhino 'Environment', so I am now grabbing the HDR/EXR from there and making a lux environment. Here is a material test render, with some lights and a studio HDR:

The first column is matte, matte translucent, matte w/diffuse and bad UV map, matt translucent with better UV map. Next column is glossy, next is glossy translucent, then shiny metal, then mirror, then glass, then roughglass. These all have various values for spec/trans/roughness/IOR/color
and rhino viewport:

The GL viewport leaves a lot to be desired, but the material previews are a little better. I need to do some testing on gamma, the colors seem to be a little off to me...also it would be nice to add an exponential taper to the gloss/roughness values.

Here is a bump map test. I'm not sure how bump maps work in lux. From example scenes, I gather that I am supposed to 'scale' the bump texture by a float value, but I'm not sure what that gets me. There is kind of a hint that the scale will be to meters, but I'm not sure. At any rate I am using the rhino % value to scale to the drawing unit, and then converting that to meters. It gives me a small number on small scenes, and seems to be working, for now anyway:

(the environment doesn't make it out of lux for some reason)

rhino viewport:

I've only tested latlong on environment mapping; I don't have any other types of HDRs handy to test other mappings but it should work for lux supported ones. There is one problem though I don't know if is fixable...the map seems to be mirrored from one app to the other:
RhinoViewport:

LuxView:

I haven't found anywhere to swap this in either app, so I may be stuck with it I suppose.

I haven't tackled transparency yet, but I don't think it shouldn't be super-difficult. After that I don't know if I am going to refine this further or move on to the dedicated lux material editor and work in the opposite direction. The lux editor is going to take alot of python that I don't know yet and also GUI work, so it will probably take a while.

If anyone has any hints on bump scaling or transparency, I'd be happy to hear them.

Thanks,

Nathan

[Lord Crc]

Great progress!

When using mattetranslucent, I'd recommend keeping the "energyconserving" option to true. This will prevent the material from reflecting more energy than shines on it, which can be a big source of fireflies, in addition to being physically wrong. When using glossytranslucent you'll need to ensure this manually, by making sure Kt + Kd < 0.8 or so (to give some room for specular reflection). Actually if you use the new glossycoating it's easier to get this right, as you can then use a mattetranslucent base material with energyconserving set to true. Then you just need to ensure Ks is set to something sane, ie < 0.25.

To illustrate, here's an example of using glossycoating over mattetranslucent to mimic glossytranslucent:

Code: Select all

# mattetranslucent base material, to be coated
MakeNamedMaterial "luxball::base"
   "color Kr" [0.0005000000 0.01500000 0.0500000]
   "color Kt" [0.005000000 0.01000000 0.02500000]
   "bool energyconserving" ["true"]
   "string type" ["mattetranslucent"]

# this is the material which is applied to the "luxball" object
MakeNamedMaterial "luxball"
   "string basematerial" ["luxball::base"]
   "color Ks" [0.12 0.12 0.12]
   "float uroughness" [0.015] "float vroughness" [0.015]
   "string type" ["glossycoating"]


Here is a bump map test. I'm not sure how bump maps work in lux. From example scenes, I gather that I am supposed to 'scale' the bump texture by a float value, but I'm not sure what that gets me. There is kind of a hint that the scale will be to meters, but I'm not sure. At any rate I am using the rhino % value to scale to the drawing unit, and then converting that to meters.

This is poorly documented in the wiki, I agree. Sorry about that, will try to fix. In any case... If you use a greyscale texture, then values of the greyscale bump texture is taken to be meters, and this is the scale of the bumps. Thus if you feed it a greyscale png which goes from fully black to fully white, then the difference is taken to be 1 meter, and the result is 1 meter high (or low) bumps. Since bump mapping only works for relatively small bumps relative to the base geometry, this is usually not good at all, and the values have to be scaled down to realistic numbers. Again if you have a greyscale image which uses the full range, and you want 5mm bumps, then you need to scale by 0.005.

There is a catch. If you use normal maps, via the "normalmap" texture, for the bumpmap parameter, then the scale is relative. Meaning you'll mostly want to use the normal map as is, without any scaling.

I've only tested latlong on environment mapping; I don't have any other types of HDRs handy to test other mappings but it should work for lux supported ones. There is one problem though I don't know if is fixable...the map seems to be mirrored from one app to the other:

We have this in blender too. What we do is we scale by -1 along the x axis, for example like this

Code: Select all

AttributeBegin
  Transform [... regular transform for orientation of env light ...]

  LightGroup "env"

  Scale -1.0 1.0 1.0  # flip x-axis

  LightSource "infinite"
      "float gain" [1.0]
      "texture L" ["envmap"]
AttributeEnd

I haven't tackled transparency yet, but I don't think it shouldn't be super-difficult.

The usual way of handling this is to set up a mix material between the "true" base material, and a null material, which is entirely transparent. You can either have a fixed mixing amount, in which case the entire object is partially transparent, or you can texture the amount if you want it to vary.

Here's an example, based on what luxblend25 generates:

Code: Select all

Texture "Tex_alpha" "float" "imagemap"
   "string filename" ["alphatex.png"]
   "string channel" ["alpha"]     # this png has alpha channel, so use that for transparency amount
   "string filtertype" ["bilinear"]
   "string wrap" ["repeat"]
   "string mapping" ["uv"]

Texture "Tex" "color" "imagemap"
   "string filename" ["alphatex.png"]
   "string filtertype" ["bilinear"]
   "float gain" [1.0]
   "float gamma" [2.2]
   "string wrap" ["repeat"]
   "string mapping" ["uv"]

MakeNamedMaterial "Material_null"
   "string type" ["null"]

# the actual base material
MakeNamedMaterial "Material_mat"
   "string type" ["matte"]
   "texture Kd" ["Tex"]   # use rgb from texture as base color
   "float sigma" [0.0]

MakeNamedMaterial "Material"
   "string type" ["mix"]
   "texture amount" ["Tex_alpha"]  # use alpha texture to mix between null material (transparent) and matte material
   "string namedmaterial1" ["Material_null"]
   "string namedmaterial2" ["Material_mat"]


Hope this helps.

[nart]

Thanks LordCrc.

Yes I did bool energy conservation on, or thought I did, I will check. I did notice that I had to back off alot of colors to make the material not go crazy. I planned on going back later and clamping/scaling things down so the user couldn't get out of the realm of reality..I figure it will take alot of trial and error though, so I thought I would move on to the larger tasks first. Just out of curiosity, and there is probably no simple explanation, but why is it even possible for the material model to produce unrealistic results?

Glossy Coating?? Where did that come from? ...Oh I see now it is called glossy2 in the source. I must have skipped over that one. Can you put that on top of any material, or just ones that aren't already glossy? I see there is a check on that. I was also going to ask about the layered material, is that good to go? I couldn't find any examples on that one.

Ok thanks for the info on the bump. I'll have to think of a good way to use it.

Normalmap texture? Where would this be in the source? And bump for that matter as well, I can't find either of them.

That sounds easy enough on the environment scale...

Thanks for example on the transparency. It is mentioned a little on the manual part of the wiki under the null material so I had a place to start, but examples are better!

Thanks again,

Nathan