By all means, I have been working on other things for the last two weeks, so please give it a try.
I hope I have not broken anything in TriMesh collision support - it seems to work in same way it used to. As for the CompositeMesh collisions, I think it is safest to just add them in current state - they seem to work for Sphere based on CompositeMesh.
I have changed OBBTree, so it now asks for triangles instead of getting them itself - so it will be possible to support other funny meshes in future, which do not hold triangle list in normal state.
Thanks, abies. I’ll take a look at this as soon as possible and give feedback.
Ok, finally got it updated… eclipse was being a pain applying patches.
It looks fine. Things run just as they did before, all old tests work as you said.
So, I don’t see any issues with committing this making use of it.
This brings me to a question. Why would we ever NOT want to use composite mesh? Where is the disadvantage, if any?
Right now it’s not easy for a user to build a composite mesh. Abies, do you see a possibility of adding a CompositeMesh(Trimesh mesh) constructor that would build a CompositeMesh from a TriMesh?
Just brainstorming here while at work. 
Update: I forgot to make use of the Sphere that extends CompositeMesh (which I named CompositeSphere). After switching to this sphere, the collision still appears to work fine, but there are missing triangles in the sphere. It looks like a wiffle ball (if you guys have those in Europe). Did you have to make any changes to the Sphere class you wrote? I’m still using the one you e-mailed awhile back.
Somehow public void draw(CompositeMesh t); has dissappeared from Renderer interface. If you will add it there, everything should work ok (waffle ball is the result of CompositeMesh being drawn by TriMesh routine).
Edit:
I think I know what was the cause of mistake. While I was updating code from CVS, few files had all lines marked as changes (due to whitespace changes we have talked about). It was not possible for me to just update it, so I overwrite my changes and applied it back. This happend 2 or 3 times in meantime and at some point I had to forgot to readd draw(CompositeMesh) to Renderer - and as it has draw(TriMesh), no error was reported.
"mojomonk" wrote:
This brings me to a question. Why would we ever NOT want to use composite mesh? Where is the disadvantage, if any?
Right now it's not easy for a user to build a composite mesh. Abies, do you see a possibility of adding a CompositeMesh(Trimesh mesh) constructor that would build a CompositeMesh from a TriMesh?
Yes, I'll add easy way to construct CompositeMesh from Trimesh. There will be probably extra parameter in constructor, to allow choosing optimalization method.
As for the disadvantage - less clarity. You need to create IndexRange, which is not necessary for simplest cases.
What we can possibly do, is to make TriMesh extend CompositeMesh and provide simplified interface for it, for people wanting to play with simple triangles.
Well, it will definately be worth considering making CompositeMesh a default leaf in the future, we gain speed and don’t lose anything (other than clarity). A future discussion, perhaps.
Do you have updated Sphere code? Or should the original sphere you sent me work?
Lastly, what’s a time frame you expect for having a Trimesh contructor? If it’s going to take awhile, I’ll go ahead and check in your stuff, otherwise, I’ll wait.
Sphere I sent you is ok - problem was with Renderer interface.
New version of stripifier classes is at http://nwn-j3d.sourceforge.net/misc/jme-stripifier.zip
You can create CompositeMesh out of Trimesh in following way
CompositeMesh cm = new GeometryInfo(triMesh).createContinousStripMesh("Test");
You can as well do
TriMesh t = new GeometryInfo(triMesh).optimizeTrianglesForCache().createTrimesh("Test");
which is way suboptimal, because everything is recomputed, but it works. Other possibilities - get basic trimesh and generate mixed strip array with smoothened autogenerated normals:
CompositeMesh cm = new GeometryInfo(triMesh).recalculateSmoothGroupNormals().createMixedArray("Test",4,false);
Things to remember:
- creating CompositeMesh from TriMesh considerably more processing than directly filling GeometryInfo
- creating CompositeMesh for very complicated objects can take a LOT of time; AFAIK complexity is O(n^2) where n is number of triangles
Would be real nice to incorporate this into a model conversion app… (conversion - with options - of your trimesh model to an optimized CompositeMesh which is then stored as a .jme file for you to use in your game.)
Problem here is that performance of various options is very dependent on model type and GPU. Maybe I will put together some kind of benchmark app which will compare various modes, so we can compare how they look like on different GPUs ?
Ok, abies, looks like there are plenty of ways to create a CompositeMesh from a TriMesh using the stripifier, so that is acceptable (although I understand suboptimal). We’ll talk later about possibly making all jME objects and model loading CompositeMesh rather than TriMesh, but we can hold off for a bit.
I got all your work into my local system here (sphere was missing the Renderer.draw(CompositeMesh), you were right), and I will go ahead and check it in after a little tweaking of comments.
After that, I will again look at the stripifier code.
Ok, checked in. TestOBBTree uses a CompositeSphere.
Locking thread to signify this code is in place. If further discussion is desired on TriMesh/CompositeMesh relationships, start in Dev General.