// if the universe is dirty (e.g. before the first frame) --> collect atoms, cull and sortif ((universe.modListener == null) || (universe.isDirty())) {// decrement the frame-id, since not all atoms might be refilled and get the new frame id.currentFrameId--;

Some tricks puzzle me a bit but I'm gonna look further.. it's not as complicated as I thought.

No. It's quite easy after I simplified and streamlined it

The universe is only set dirty, when a Group is removed. And I'll change this behaviour tomorrow or so. When a Node is added, it is added to the Atoms list or traversed in ase it is a Group. But the already existing Atoms don't need to be rebuilt. When a Node is removed, I've set the universe dirty and it is completely retraversed. The universe doesn't need to be retraversed even in case of a removed Group. But the Atoms must be removed one by one. I'll implement this behaviour tomorrow.

Ah! A thought is coming to my mind: The universe needs to be set dirty in case a Link is removed. I'll change that.

I traced the Link / SharedGroup problem a little further and found some bug, that made it not work. But now I face a problem, why it even can't work. And I can't see why they worked before.

Amos, please have a look at AtomsCollector's / FrustumCuller's collectLinkAtoms methods. They're taken from the previous version as is. The problem is, that the shared shapes will always be drawn at the exact same place, because the shape's localtovworld is updated in each SharedGroup. And I don't have an aidea at the moment, how this can be solved. And as I sayd, I couldn't have worked before.

I traced the Link / SharedGroup problem a little further and found some bug, that made it not work. But now I face a problem, why it even can't work. And I can't see why they worked before.

Amos, please have a look at AtomsCollector's / FrustumCuller's collectLinkAtoms methods. They're taken from the previous version as is. The problem is, that the shared shapes will always be drawn at the exact same place, because the shape's localtovworld is updated in each SharedGroup. And I don't have an aidea at the moment, how this can be solved. And as I sayd, I couldn't have worked before.

I'll look at it later. But I do have the idea to solve the problem for links drawn at the same place. Do you remember the RenderBucket class. It was exactly to handle this problem. Well, I can't easily reactivate them, since they would produce a lot of garbage. But I'll find a solution. But it could be tomorrow, not today, ok?

I'll look at it later. But I do have the idea to solve the problem for links drawn at the same place. Do you remember the RenderBucket class. It was exactly to handle this problem. Well, I can't easily reactivate them, since they would produce a lot of garbage. But I'll find a solution. But it could be tomorrow, not today, ok?

OK for now I'll provide an option in PrecomputedAnimation to *not* use Display LIsts.

I found the solution for the problem to draw shared Shape3Ds on the right places and it works. But I need to further test it before I commit it to avoid sidekicks, since it is one little deeper change. Please have a littel more patience. I'm very tired now and had a hard day at work. I'll hopefully comit it tomorrow.

Marvin

PS: I've changed the org.xith3d.test.etc.SharedGroupTest to test Link removal. When you hit SPACE, one of the Links is removed from the scenegraph and it is properly removed without problems (even if you won't see it, since the patch is not committed). Please check, if it is the same test case as in your game.

I found the solution for the problem to draw shared Shape3Ds on the right places and it works. But I need to further test it before I commit it to avoid sidekicks, since it is one little deeper change. Please have a littel more patience. I'm very tired now and had a hard day at work. I'll hopefully comit it tomorrow.

Marvin

PS: I've changed the org.xith3d.test.etc.SharedGroupTest to test Link removal. When you hit SPACE, one of the Links is removed from the scenegraph and it is properly removed without problems (even if you won't see it, since the patch is not committed). Please check, if it is the same test case as in your game.

Maybe I've forgotton to mention, that I don't remove Link from the sg anymore. Instead, I use setSharedGroup().However, your test seems correct. I hope the solution you've found to draw shared Shape3Ds will be fine, thanks again for your work.

Maybe I've forgotton to mention, that I don't remove Link from the sg anymore. Instead, I use setSharedGroup().However, your test seems correct. I hope the solution you've found to draw shared Shape3Ds will be fine, thanks again for your work.

I've changed the SharedGroupTest to behave exactly like you described and it runs without any problems.

Unfortunately I cannot test shared groups in real world right now as I'm deeply rewriting essential parts of my game (architecture revamp, slowly acting with purpose so that network support has mood up).

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