Hey Sam, as you know ;-) we don't load all the geometries in our scenes and we assign the shaders to the geometries during ribgen (and we generate the rib geometries at the same time btw).

As you suggested, until now we are assigning the shaders to invisible planes. It works well except when you include them in a rib archive. The rib archive bounding box includes the invisible planes which is not good when the geometries are not near them. You end up with a much bigger bounding box then necessary.

So I was hoping there would be a 'magic' attribute  that would force the injection of the shader into the rib.

Christophe.

finding the middle of the scene requires extra work and is not always trivial (specially if the geometry is moving). I'll have a try with a radius 0 or 4 identical vertices, but I am pretty sure it will affect the rib archive bounding box.
An attribute on the shader would be the most flexible and robust approach.

Christophe.

No worries.
Can we have an attribute on the shader ? pretty please :).

Because the geometries are not in the scene so we don't have anything to connect to.
For example:
Say we have a scene that contains lots of jeeps. Each jeep is made of 100 geometries. We have in house tools that just load the bounding box of each jeep (which is very memory light weight) and we load one palette of shaders common to all jeeps. We store in a file the connections between the shaders and the different geometries of the jeep. During ribgen we read the file and assign the shaders to the different geometries (and also inject the geometries in the rib).
Having the shaders live in the scene allow the lighters to modify the parameters and do interactive renders with the modified values.

Christophe.

christopheb wrote:

No worries.
Can we have an attribute on the shader ? pretty please :).

I'm not sure. IIRC, that would be a pretty big change in how the export works. It's more like adding a whole new "export shaders by themselves" feature than a simple attribute as right now, I think we never even see the shaders which are not connected.

So connecting them to an object which would have no effect might still be the best solution. Is there any problem with this besides the bounding box of the archives you write? Also, if you're using this to integrate objects in the scene for rendering, why are you exporting another archive from that scene?  Is it hypershade networks or renderman shaders you want to export?

olivier wrote:

christopheb wrote:

No worries.
Can we have an attribute on the shader ? pretty please :).

I'm not sure. IIRC, that would be a pretty big change in how the export works. It's more like adding a whole new "export shaders by themselves" feature than a simple attribute as right now, I think we never even see the shaders which are not connected.

So connecting them to an object which would have no effect might still be the best solution. Is there any problem with this besides the bounding box of the archives you write? Also, if you're using this to integrate objects in the scene for rendering, why are you exporting another archive from that scene?  Is it hypershade networks or renderman shaders you want to export?

Olivier, you got it, there is no other problem beside the bounding box of the archive we write. If that can be solved then we are rolling.
I am not sure I get your second question. I'll try to explain one workflow. Say we are rendering different shots of a big city. From a master scene we would export the different part as rib archive which would contain the shaders and geometry. We then assemble the different parts for each shot with rib archive nodes.
We are exporting renderman shaders.

Last edited by christopheb (2012-02-01 15:29:32)

christopheb wrote:

ogre wrote:

Can you connect one of your model's 'center' attribute to 'translate' of your dummy geo ? This way you BBox doesnt grow on animated geometry

That might be able to work if the model is part of the rib archive we are exporting. The dummy geo can be shared between multiple models.
i.e: all the wheels of all the jeeps share the same shader.

But there has to be something in that archive. It doesn't matter what you attach the dummy geo to. As long as it gets exported in the archive too then the dummy geo will not make the bounding box any larger.

The other way would be to have some kind of geo which has no effect on the bounding box. I can't think of any obvious way to do that besides having 3dfm explicitly ignore it...

Ok will do. Thanks for all the replies !!