On 6/18/07, Eric Maslowski <[EMAIL PROTECTED]> wrote: > >> 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?
I should correct myself. we are using the RenderBitmap method. But currently in the case of a BitmapTex we just get it from the Bitmap object. We do currently have a max resolution of 4096x4096. In the case of procedural textures we default to a 512x512 texture. This should be configurable, but we have not had time to do this yet. > > >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. There is actually already support for the self illumination channel. While this has not been tested as much as the other maps. We have used it in a few projects. I wish I knew more about this process, but I didn't work on creating the light maps. -Aron > 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
