>> I agree, it would make things quite complicated. Does OpenSG do any clever >> culling of lights based on their distance from an object. (e.g. if an object >> is outside of a lights attenuation range, the object isn't illuminated by >> it) In this case, I would imagine such control over a lights location in the >> graph would help with large scenes with many localized lights.
>I am not aware of any support for something like this in OpenSG. It >would definitely be an interesting addition though. [Eric Maslowski] I need to learn more about the internal rendering pipeline first, but maybe this is something we'll tackle after we get a few other things out of the way (e.g. physics and animation). It could be a nice optimization for your typical "game-level" style environments. > You are right we are using the RenderMap call. Copying over the > opacity map is definitely a good idea. I will put it on the list of > things to do. Thanks for the suggestion. :) [Eric Maslowski] Since you're using RenderMap, where do you get the resolution for the map from? The original file? What about for procedurals? >Very good point. Originally we created unique OpenSG materials and >textures depending on the 3ds Max pointers. So if two different >objects share a pointer/instance to a material then they share the >same OpenSG material. The same applies for textures, as long as they >are 3ds Max instances and not copies they share the same texture. We >ran into a few problems with this though when we started baking >textures. This was caused because after baking each object gets a >shell material which has it's own copy of the original texture. To get >around this we started using the bitmap filename as unique id rather >than the pointer. This does have the disadvantage that currently the >plug-in assumes that all bitmap textures that share the same source >filename are treated like instances and not copies. This could be >configurable so that you can choose which way to identify unique >bitmap textures. [Eric Maslowski] Ah, I see. I'm not a huge fan of special cases, but maybe this is one worth considering. Perhaps a check is made to see if the material is Shell, if so we assume it was generated by render-to-texture. We then specify it as being unique (since by definition all render-to-texture maps are unique), and we only process the baked channel. In a time long ago, we just required artists to create new materials for the render-to-textured objects as a final step, but we always looked for a more elegant solution. Out of curiosity, are there any plans to support the illumination channel or the RGBMultiplier for LightMap effects? I don't know about others, but the majority of our render-to-texture use comes from lighting/shadowing and not the tiling of textures. In fact, we always look for ways to keep our textures tiling and have the lightmaps sitting on top of them to keep memory usage down. Thanks again for the great work thus far on this plugin. Let me know if you need anything from my end (other than the docs when they're completed). Cheers E. ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
