Hi, On Thu, 2009-06-18 at 14:21 -0500, Carsten Neumann wrote: > Hi Gerrit, > > Gerrit Voß wrote: > > On Thu, 2009-06-18 at 11:12 +0800, Gerrit Voß wrote: > >> On Wed, 2009-06-17 at 21:44 -0500, Carsten Neumann wrote: > >>> The reason I think this also affects the new stuff is because it is > >>> before that actually gets a chance, i.e. the DrawEnv::activateState > >>> short circuits the state change before it gets to any infrastructure > >>> specific code. There is also a bug in SHLChunk::changeFrom, see the > >>> "Graph operators & OSG shader variables" thread on the users list for a > >>> patch. > >> unfortunately there is more wrong. My quick test gives me weird results > >> such as switched of lights where they should not. So I guess I have to > >> dig a little more ;) > >> > > > > ;), after fixing this the good news is, the new infrastructure actually > > does it right, because the overrides are different so the > > oldOver != newOver test succeeds and it goes to changeTo. > > hm, why are the overrides different? Offhand that sounds a bit odd, > given that we are talking about two objects with same material.
with all the caching the new shaders, like lights, are always overrides. And laze handling of those is still only on my todo list ;( > > Actually > > to often for my liking so I see if I can get an early out for the > > case where only the shader params change. > > > > Sadly that does not really help us with the old OSG1 derived stuff ;(. > > One question though is is the compat stuff good enough so we can remove > > the original implementation and don't worry about it. > > Well worst case we can take out the test if the old shaders are active. > > hm, ok. > Related to that: How about dropping the old stuff and only keeping the > compatibility layer of the new infrastructure? What is the difference > between the two - is renaming SHLChunk to SimpleSHLChunk everywhere > enough to convert an app? With compat enabled there should actually be typedefs so you should still be able to use SHLChunk. The main problem might be that all the intermediate classes are gone, but maybe we can just typedef those too. I'm also not sure the interfaces are 100% identical. And we would have to update the osb loader. > I understand this does not help with the update problem, as you said the > compatibility layer is also affected, but it would reduce the number of > combinations that folks can build. > > > Let's see where the early out takes us, maybe we can reuse some bits. > > Let me know if I can help implement this, just tell me what your ideas > are and I'll see if I can come up with the right code ;) Actually the early out stuff was not really needed right now. There was an easier way utilizing the knowledge which chunk needs to be updated, So shader proc vars should be updated correctly. The problem with telling things is, usually once I know where I want it to go it is easier/faster implemented than told ;) The good thing is I can take a look at the whole state changing thing and rework/optimize it as I had planned for some time. kind regards, gerrit ------------------------------------------------------------------------------ Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org _______________________________________________ Opensg-core mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-core
