Exporter for Rhinoceros

[nart]

Hello all-

I see it has been about 6 months since there was any activity about an exporter for Rhino....is anyone working on this?

I ask because I have been tinkering with trying to produce something with RhinoPython in the V5WIP, and I am to a point that I need to decide if I want to continue. I don't want to duplicate any effort.

What I've got so far is suface and polysuface render mesh export, mesh geometry export, camera export, sun export, and support of blocks (non-nested) as transformed instances. I've attached some screen grabs to show this:

rhino viewport:

lux output:

rhino viewport2:

lux outpout2:

I also tried nurbs exporting, which I think would really be neat if it is possible to support trimmed surfaces, and to dynamically tessellate as a function of pixels, but I don't think these things are supported...at least not from what I was able to gleam from the scene file doc. Here is an example:

rhino viewport:

and the lux output:

The deformed plane and torus worked, but the others didn't. I did have to pad 2 knot values to get the parser to accept them, so maybe that wasn't the right thing to do but it seemed to make any difference what numbers I used, so I just duplicated the first and last. If anyone has tips about this I would appreciate it. But, if it is not possible to used trimmed surfaces then it is probably not worth it.

Also, I am really interested in trying to get pylux to work, as dumping this stuff to text files can get pretty slow if the scene gets complicated or has dense meshes, but I'm having trouble figuring out how to a) get all the modules and dependencies and b) get them imported into the rhino python IDE. If anyone has any tips on that kind of stuff then I would appreciate that as well.

At any rate, I just thought I would see if anyone else is working on or is interested in this.

Thanks,

Nathan

[J the Ninja]

Nothing to my knowledge. Congrats, your scripts are now the new LuxRhino.

[paco]

Nice results! I think that there is nurbs code floating around in the core but it hasn't been updated/used in a while.

[nart]

Ha, well, its got a long way to go before I would call it LuxRhino.......but I guess I will continue on and perhaps one day it shall be so.

[patro]

hi nart, your efforts are welcome
you could ask Exvion if he can share part of his code or to join forces to... iirc he was playing around materials...

[Sheltem]

Noooice!!

S

[jeanphi]

Hi,

Great progress, congratulations! For the NURBS issue, it might be interesting to provide us with an example source data from Rhino (the values, not a Rhino file), along with reference views so that we can try to pinpoint the issue.

Jeanphi

[nart]

Hi,

Great progress, congratulations! For the NURBS issue, it might be interesting to provide us with an example source data from Rhino (the values, not a Rhino file), along with reference views so that we can try to pinpoint the issue.

Jeanphi

Hello Jeanphi-

I have attached the scene files for the above example. The nurbs data is in the scene-geo-nurbs.lxo file. As I mentioned, the parser requires two additional knots in the U and V directions than Rhino provides, so based on this page:
http://www.rhino3d.com/nurbs.htm, I just duplicated the first and last knots. I also couldn't find out any info on what the 'nurbs::u0/nurbs::v0' parameters really mean, so I just left it at default. I must admit I don't really understand the mathematics behind nurbs surfaces, so I don't really know what it would take to get trimmed surface support, nor have I found anything in Rhino that says 'this is the trim data for a surface', but without trimming I don't really see the justification for supporting the nurbs primitive. But I am happy to help if someone wants to work on it.

Thanks for everyone's replies.

Nathan

[jeanphi]

Hi,

I think that duplicating the first and last knot values is the right thing to do, and the page you linked, there's actually a sentence on this, but it is quite vague: it just says that some modellers have 2 more knots and that Rhino takes care of that by itself when exporting or importing data.
The u0, u1, v0, v1 values can be kept as is, they just allow to change the rendered part of the curve: values must be between the lowest and highest knot values with u0<u1 and v0<v1, maybe they can be used to trim the surface.
I think the issue with your exported data might be the order of u and v control points in the P list. I guess your outer loop is on u and your inner loop on v, while LuxRender expects the opposite (don't ask why).

Jeanphi

[jeanphi]

Hi,

I can confirm the control point ordering issue, swapping the points as suggested fixes the shape. However regarding the knots, it is probably slightly more complex because the shape are not as regular as they should be. Maybe having a look at OpenNURBS might help.

Jeanphi