I'm working on procedurally created models, to be rendered with Pixie. However, I'd like to get some feedback on approach. Is it necessary to link to the ri.h directly as opposed to just writing a text file (RIB) based upon my internal model/geometry. I ask this because, I'd like to work in Java/JOGL to previsualize, but get the quality of Pixie. I understand that to the renderer, these inputs are the same. So am I putting myself to any disadvantage -- am I missing out on something wiz bang that I could only do through directly linking to ri.h?
Thanks in advance.
j
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The advantage of linking to ri.so (using ri.h) to define the interface is that Pixie has to do no parsing whatsoever on text files. Additionally, you can write shared-object plugins (delayed objects) which instance geometry into Pixie. This is useful when you wish to do LOD control such that particular parts of a scene instance at a (programatically generated) level of detail, and cost virtually nothing if they're not rendered (culled out of the scene).
You probably cant (without some major magic) dot the instancing using java.
You could output to Pixie using either Java->RIB Java->ri.so using JNI to bind the RI interface into Java though.
RISpec defines the renderman interface, and it is has both C and RIB bindings. There are some subtle things you may only be able to acheive via C / C bound via JNI.
So basically it's up to you, and will depend on the kind of thing you're trying to acheive.
If you wish to do procedurally generated geometry in a larger scene, I'd probably previsualize in whatever you like, then write the interface in C and instance the geometry into Pixie. That would also allow you to model the non-procedural components in maya or whatever.
If you want the whole thing procedural, I don't know that it matters much - though I would say that a RIB binding will allow you to edit things like shaders much easier if the time taken to generate a scene is significant.
As a final thing to throw into the equation, the Pixie C interface can be used to write RIBs thus avoiding having to interpret the RiSpec to determine the correct fprintfs to do.
Hope that helps
Cheers
George
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You brought up some great points. Sounds like it's C++ time. Ultimately, I will probably combine models created in other software, with procedural geometry. Sounds like binding those two at RIB generation with ReadArchive would be tough and not as flexibile as a procedural. So I'd be looking at something like:
Create procedural geometry by linking to ri.h (thus avoiding converting to RIB, then reintegrating into larger RIB strucutre).
Output to RIB ASCII instead of directly to renderer through pipe. That would give me the flexibility to tweak shaders and options for final output per your suggestion.
Brush up on C++. LOL.
Thanks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm working on procedurally created models, to be rendered with Pixie. However, I'd like to get some feedback on approach. Is it necessary to link to the ri.h directly as opposed to just writing a text file (RIB) based upon my internal model/geometry. I ask this because, I'd like to work in Java/JOGL to previsualize, but get the quality of Pixie. I understand that to the renderer, these inputs are the same. So am I putting myself to any disadvantage -- am I missing out on something wiz bang that I could only do through directly linking to ri.h?
Thanks in advance.
j
The advantage of linking to ri.so (using ri.h) to define the interface is that Pixie has to do no parsing whatsoever on text files. Additionally, you can write shared-object plugins (delayed objects) which instance geometry into Pixie. This is useful when you wish to do LOD control such that particular parts of a scene instance at a (programatically generated) level of detail, and cost virtually nothing if they're not rendered (culled out of the scene).
You probably cant (without some major magic) dot the instancing using java.
You could output to Pixie using either Java->RIB Java->ri.so using JNI to bind the RI interface into Java though.
RISpec defines the renderman interface, and it is has both C and RIB bindings. There are some subtle things you may only be able to acheive via C / C bound via JNI.
So basically it's up to you, and will depend on the kind of thing you're trying to acheive.
If you wish to do procedurally generated geometry in a larger scene, I'd probably previsualize in whatever you like, then write the interface in C and instance the geometry into Pixie. That would also allow you to model the non-procedural components in maya or whatever.
If you want the whole thing procedural, I don't know that it matters much - though I would say that a RIB binding will allow you to edit things like shaders much easier if the time taken to generate a scene is significant.
As a final thing to throw into the equation, the Pixie C interface can be used to write RIBs thus avoiding having to interpret the RiSpec to determine the correct fprintfs to do.
Hope that helps
Cheers
George
You brought up some great points. Sounds like it's C++ time. Ultimately, I will probably combine models created in other software, with procedural geometry. Sounds like binding those two at RIB generation with ReadArchive would be tough and not as flexibile as a procedural. So I'd be looking at something like:
Create procedural geometry by linking to ri.h (thus avoiding converting to RIB, then reintegrating into larger RIB strucutre).
Output to RIB ASCII instead of directly to renderer through pipe. That would give me the flexibility to tweak shaders and options for final output per your suggestion.
Brush up on C++. LOL.
Thanks.
You can still use Java.
http://www.posthorizon.com/RenderMan-java/
I wrote a RIB export plugin using Java for this project
http://p210.ezboard.com/bggaliens