OBJ, VRML and other polygon based formats.
Brought to you by:
mikaelc
Menu
▾
▴
I've had a few requests for export in OBJ, VRML and similar polygon based formats.
While possible, it is slightly more tricky than exporting to raytracer scene description formats like the ones used by PovRay or SunFlow.
This is mainly because Structure Synth and the template export system internally operates with Sphere and Box primitives - and a format such as OBJ only allows triangles: thus it becomes necessary to triangulate the spheres (and specify normals for each vertex) before outputting them. So the template rendering system would need to be rewritten.
I believe a better approach would be to export the Structure Synth models, and convert the models into polygons in another program such as Blender. See here for information about using Blender together with Structure Synth:
http://blog.hvidtfeldts.net/index.php/2008/06/third-party-structure-synth-export/
The link exists but the pages linked to on it are all missing :-(
The Blender templates and python scripts are at:
http://www.luxrender.net/forum/viewtopic.php?f=14&t=585
They work for me - perhaps they were just temporarily down?
ahh you have to be a member...
P.S. any chance you could use the windows EOL characters so that outputs of the "Template Render to File" command can be edited easily in simple apps like wordpad ?
At the moment - when rewritten from WordPad - they all collapse to one line.
Oh - I hadn't noticed that the EOLs were not CR+LF. I will fix this.
In the meantime let me suggest Notepad++ (which is both excellent and free)
Extending the discussion of meshes etc.
I tried using affine transforms on the box - not expecting it to work.
But in Structure synth it does allow distortion of the box shape so pyramids etc are possible.
But sunflow rejects the box as no good to render. See my flickr photostream for an example.
Of course the Renderers are all expecting to render simple scaled objects at locations defined by Structure synth.
But if I want a pyramid shape, etc then its not currently possible, and simply adding more procedurals may not be the best long term answer.
E.g. for the city I would like to make non-rectangular grid shapes for placing 4 sided but non-rectangular buildings.
But this does not yet seem possible.
As a possible halfway suggestion:
How about modifying the mesh object so that the number of sides can be set and an operator to cap the end made available (or automatic somehow).
Ideally also a way to indicate starting a new mesh.
Hi,
I still haven't figured out exactly how the 'mesh' primitive can be made useful, and I don't think it will ever be able to do what you want.
But... I think I will add a 'polygon' primitive, making it possible to specify individual triangles (with coordinates expressed in the local coordinate system). This would make it possible to build more complex composite objects, e.g.:
Rule Pyramid {
Polygon[0,0,0;1,0,0;0.5,0.5,0.5]
Polygon[1,0,0;1,1,0;0.5,0.5,0.5]
Polygon[1,1,0;0,1,0;0.5,0.5,0.5]
Polygon[0,1,0;0,0,0;0.5,0.5,0.5]
}
They will of course obey transformations like the other primitives: e.g.:
{ size 10 1 1 color black } Polygon[0,1,0;0,0,0;0.5,0.5,0.5]
I think this will be quite generic and easy to implement, but of course any suggestions are welcome!
That would be fantastic and just what I'm looking for! I can only imagine what others will be able to create with it, too.
Here are some thoughts:
1) I think that the triangle approach to defining surfaces is probably the most useful (and easiest to implement) since more than three points is not necessarily co-planar. But in that case, the primitive should probably be called "Triangle" rather than "Polygon."
2) I would hope that the current export templates would be able to handle that structure (e.g., the sunflow export template that I enjoy so much).
Think of all the fun with stellated polyhedra, etc. that could be done with this. Some *very* interesting possibilities: tori and other truly tubular structures, a tube that could smoothly coil into itself, and basically any other geometry. It might be possible, then, to import triangle meshes (as sequences of triangle coordinates) from other 3D apps for further recursive tweaking in structure synth.
Looking forward to the release that contains this triangle feature!
You are right about the naming, 'Triangle' would be a better name. And of course it should be possible to export to the template rendering system.
I don't think this polygon approach will be able to do what you really would like to do, though :-(
It would become possible to define more complex primitives, and then use these primitives instead of the 'Sphere' and 'Box' primitive. But the rules in Structure Synth do not depend on the shape of the drawing primitives - so creating a new composite primitive would be more like creating a new 'brush' for drawing. For instance it would be possible to create a pyramid shape which could be used for generating rooftops in city like structures (as I believe the author of the first post intends to do).
When you talk about 'stellation' and importing structures into SS and applying recursive rules to them, I believe what you would like to have, is rules that operate directly on the polygons - for instance rules for extruding or splitting polygons. I've been thinking about this for some time, and have been looking at a few other ideas (such as CGA grammars), but I am not sure about the right approach yet. Ideally I would like something that 'mixes in' with the existing EisenScript, but it might not be possible to do so in a clean way...
But working directly on the polygons in a structure is definitely something I am very interested in!
Extruding and splitting may be very difficult.
How about extending your basic triangle primitive (what already :-)) to allow sharing of vertices.
I.e. to keep a vertex list and a face list.
This way maybe an operator could add to these lists and so add to the geometry. All systems seem fine with rendering interpenetrating polygons (unless you want glass) so the complexity of extruding and cutting may be avoided at this time.
It also means a user could construct certain kinds of geometry like a tube of spiraling faces by adding to the last one edge and using a vertex index from N vertices before.
The normals should not be a problem. Face winding is generally used to determine the outer normal for geometry without explicit normals. So this could be configured to be Left or right hand by the order the faces are described. Also most systems have an allow double sided rendering mode to allow for either winding and sheet surfaces with only one edge.
e.g. Rule Pyramid {
Vertices [0,0,0; 1,0,0; 1,1,0; 0,1,0; 0.5,0.5,0.5]
FacesTri[0,1,2; 1,2,3; 0,1,4; 0,3,4; 1,2,4; 2,3,4]
}
This would also allow models to be imported simply - as this is basically the obj or ase text formats without extra stuff.
Perhaps (one day) a #define like:
#define Pyramid (load_obj, path)
This could also be a way to start on getting a material definition in so that too can be embedded. This could be renderer specific to start with (e.g. Mat_sunflow, etc)
Yes, I will consider extending the syntax to create more advanced polygons.
I agree, that extruding and splitting (e.g. making a polygon modification based grammar) may be difficult, but I think it could be very interesting to see what this could lead to.
Wrt to the normals, it is no problem just to create normals that are orthogonal to the base triangle, but for more complex (e.g. round) shapes better normals are needed for realistic lightning (it was this I was thinking of). The winding order is no problem either since face culling can easily be disabled.
I think that any render specific material extensions would be a bad idea - it would spoil the simplicity and I don't think it is necessary. Instead add type specifiers, like 'sphere::reflective' to the existing primitives, and then use the customized template syntax: [substitution name="sphere" type="reflective"] to setup any special materials.
Regards, Mikael.
I think this would be a great start and a fantastic addition :-)
great idea for a simple implementation
I've implemented the custom 'triangle' primitive - for an example see here:
http://www.flickr.com/photos/syntopia/3167827230/
Mikael-
Thanks so much for putting this feature in. I'll have to try it out when I can, but I'm afraid that I don't have the knowledge to compile the binary for my OSes (Mac OS X or WinXP Pro), so I'll probably be stuck waiting for the 0.9 release. :-(
BTW, some stellation doesn't actually require extruding objects to get the desired result, for example, the stellated dodecahedron: http://en.wikipedia.org/wiki/Small_stellated_dodecahedron
--DCP
Whoops! Here's a better example of stellation (the octangula) with just tetrahedra: http://en.wikipedia.org/wiki/Stella_octangula