I mean just to continue discussion and do not get as personal critics - you did a great job anyway.

I plan to intensively use Xith3D core (maybe, toolkit not too much), so I want to have it production quality on the other hand, but I also do not want to break anybody's code by introduction of incompatible changes. You know, I prefer minimalistic changes.

So "attend" means "please check if I understood your ideas behind correct and explain if not".

ShapeAtom.updateShaders(...) actually is called from Appearance.verifyChange(). This method is called from ShapeAtomPeer.renderAtom().

Yes, I see, and this explains why I get the result of "only one wrong frame just after the changes", so 2nd and other subsequent frames are OK.

Updating shaders in renderAtom() is too late - it should be updated BEFORE sorting pass. So if you check the changes I made to CVS now I placed this call immediately when atoms are collected (added) during re-cull.

Quote

I don't fully understand this shaderId thing.

This thing comes from very first versions of Xith3D, I think I have explained how it works a year or so on this forum. But with great pleasure I will explain you the idea and why updating shaders in renderAtom() is too late.

As you see, for each (in general words) appearance component type there is a shader. For each by-value-unique appearance component the core makes unique stateId which is assigned using a map (StateMap) - when creating a shader, map is looked up for the appearance component and if exactly equal shader has already been created, and if so, take its stateId (creating a new stateId otherwise).

Now, after stateIds are assigned, core on atom-by-atom basis executes the shaders and AFTER (!) calls renderAtom(), so if you update shaders there core will execute shaders at least once with old stateId's assigned before the change.

The problem is that the core can decide to skip actual shader execution if it sees that the shader of given type with specific stateId was already executed just before, so if two shaders with different characteristics will have the same stateId, one may be skipped while have to be applied in order to get correct rendering result.

P.S. Unfortunately, I can not stay always on-line, so some responces are a bit delayed.

Yuri, in case you ever disappear again for several weeks/months, could you please write a detailed doc on the core (once it's stable again, of course) so I and others can get how it works in a way easier than reading 5 classes in parallel to find what comes from where and goes where by which mean and when ?

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org