Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - mystara

Pages: 1 2 [3] 4 5 6
Support / Re: Md3 and MD5
« on: July 03, 2009, 04:00:48 pm »
I started an MD5 loader, but never finished it. I just don't have enough knowledge about JPCT to create it.

If anyone wants to take over, I'd be happy to send then what I'd done so far.

Support / Re: Md5 Importer
« on: January 19, 2009, 11:23:56 am »
I had been under the impression that exporting keyframes from an MD5 was extremely difficult, since it's a skeletal animation.

With respect to my part done port, I'd be happy to send the code to anyone who can complete it.

Support / Re: Md5 Importer
« on: January 18, 2009, 12:37:24 pm »

To be honest, I'm even struggling to find MD3 models. This is deeply frustrating as I figured that finding the character models would be the easy bits - what with the degree to which all these fps games can be customised :(

Support / Re: Md5 Importer
« on: January 17, 2009, 07:46:44 pm »
Yes, I believe MD5 uses skeletal animation.
It's the animation I'm interested in, since I'm trying to find an animated humanoid models. Most of the ones I've found are suitable for testing, but little else beyond that.

The code I've been porting seems to contain a basic skeletal animation. But as I say, there are some bits I haven't been able to figure out how to convert to. MD5 seems to allow parts of the model to be dynamically swapped in and out, removing the 'gun problem' from MD5s, which seem to be quite easy to find.

MD3 leaves me with the same problem of how to import it.

It's just so hard to find good animated MD2 models! :(

Support / Md5 Importer
« on: January 17, 2009, 06:59:35 pm »

After many months of failing to find good MD2 models for humanoid animation, I started looking in to MD5s.
Has anyone manager to product a JPCT importer for MD5 models? Or are there any plans to include one in JPCT in the near future?

I had a go at porting the jMonkey MD5Importer. By removing all the jMonkey references, and using a couple of classes from Cyberkilla's skeletal API, I've managed to make most of the classes compile. But I just don't know enough about JPCT to complete it.

Support / Re: Animatable humanoid model
« on: June 09, 2008, 09:47:09 pm »
That would be good.


Support / Re: Animatable humanoid model
« on: June 08, 2008, 05:30:32 pm »
I guess it depends how obvious it is that they're meant to be holding a gun :)

I don't suppose I can put in a request for an MD3 loader? I think they also use keyframe animation and they seem to be slightly more numerous around the web.

Support / Re: Animatable humanoid model
« on: June 08, 2008, 12:23:28 pm »
That's excellent! Thanks!

Any other clues for MD2 locations? :)

Support / Animatable humanoid model
« on: June 01, 2008, 02:18:34 pm »

Any ideas for where I might find an animatable 3D humanoid model suitable for JPCT? Preferably as generic as possible, not holding a gun and so on.


Support / Re: Argh! setScale collisions!
« on: May 19, 2008, 11:10:40 pm »
Through trial and error (yeah, scientific), I suggest that the following code is somehow responsible:


OcTree oc = new OcTree(level, 100, OcTree.MODE_OPTIMIZED);

level.setOrigin(new SimpleVector(0,0,0));

Which is my rebuildOctree() method mentioned above.
Whenever I disable this function, I cannot cause the above exception to occur.

Is there any reason why I shouldn't be able to call this code? Or any reason why it should cause buffer to become null? (even briefly?)

Support / Re: Argh! setScale collisions!
« on: May 19, 2008, 11:03:22 pm »
I'm sure you're getting fed up of this by now. But I believe there is still another bug regarding scaling (or possibly my code).

My main rendering loop looks like this:

while (true)

I have a Java GUI which can set the scale of an object via the functions:


Occasionally, seemingly randomly, when I set the scale of a loaded object, I get the following exception:

Exception in thread "main" java.lang.NullPointerException
at com.threed.jpct.Object3D.render(Unknown Source)
at com.threed.jpct.World.renderScene(Unknown Source)
at MainWindow.mainLoop(

Where line 217 of MainWindow refers to the line theWorld.renderScene(buffer); (above).
Now the weird bit here is that if theWorld was null, the exception stack wouldn't show entries for Object3D.render and World.renderScene (I believe) and buffer cannot be null, because the previous line uses the buffer object.

My previous investigations suggested that *something* to do with scaling caused buffer to be set to null, but I couldn't for the life of me manage to narrow it down.

Any ideas? It seems non deterministic, so I can only assume it's some kind of synchronisation error between my Java GUI affecting an item and perhaps messing up the buffer as the buffer is being accessed by that function but immediately after the clear() function?

Support / Re: Argh! setScale collisions!
« on: May 18, 2008, 02:14:10 pm »
Excellent. Thanks for your help!

Support / Re: Argh! setScale collisions!
« on: May 18, 2008, 01:29:12 pm »
The problem is that I cannot tell in advance what order they'll be stored in the XML :)

With regards to the bug, when this is fixed, will the calcNormals line no longer be needed?

Support / Re: Argh! setScale collisions!
« on: May 18, 2008, 01:09:23 pm »

I added a calcNormals() to level and it works correctly. I possibly should have said that I'm doing the scaling dynamically. A long time after the structure is actually loaded.

I'm sorry, this perhaps should have been painfully obvious to me. But my 3D skill is limited. I more or less understand concepts like using triangles and UV coordinates. I also understand pure maths like how to manipulate a matrix and what a normal is. But beyond that, I understand nothing.

One quick side request actually.
Might it be possible for the XML format to contain the name associated with a light source? It seems that once a light source is stored in XML format, there is no way to refer to it so that it can be later modified. Unlike, for example, models which can be searched by name with World.getModelbyName(String)?

Support / Re: Argh! setScale collisions!
« on: May 18, 2008, 12:21:19 pm »
I am using a 1f model, scaling it via .setScale(8)
Then when I do .rotateMesh(), the lights increase (I also do a .setScale(1) after this, but that seems to have no real effect).

I have tried printing the results of .getScale() immediately before and after I do .setScale() (which is immediately before .rotateMesh()). My code, and the corresponding output are as follows:

Object3D level = getWorld().getObjectByName("level");
System.out.println("First scale test is: " + level.getScale());
System.out.println("Second scale test is: " + level.getScale());


First scale test is: 1.0
Second scale test is: 8.0

Pages: 1 2 [3] 4 5 6