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
46
Support / Re: Argh! setScale collisions!
« on: May 18, 2008, 10:31:57 am »
Okay, I've been struggling with this for hours. At first I didn't notice that the XML file exports light sources (D'oh).

Everything is perfect if I only use ambient light. The structure, positions, and light are all correct.

However, if I add a light source, it appears significantly more powerful when rotateMesh() has been applied and it doesn't seem to matter whether the light itself is created and added to world before or after rotatMesh() is called.

I have uploaded a couple of screenshots to show what I mean:
<a href="http://alan.alwebwiz.net/withrotate.png">With_rotate</a> shows what happens if rotateMesh() is applied
<a href="http://alan.alwebwiz.net/withoutrotate.png">Without_rotate</a> shows what happens if it is not applied

I have tried to put the camera in almost exactly the same position. The actual locations and facings are shown in the corner. The only lines I have commented out are:

area.rotateMesh();
area.setScale(1.0f);






47
Support / Re: Argh! setScale collisions!
« on: May 17, 2008, 07:59:45 pm »
My knowledge of JPCT and 3D are very limited, but I think I understand the problem here. What you're saying seems to make sense and would explain why scaling my unscaled model (via .setScale) to large values doesn't work.

The only thing I don't understand is why the problem doesn't occur when I load the already scaled model. Surely the same transformation to ellipsoid space occurs and the same accuracy error should occur?

Isn't there some way to load the unscaled model and somehow transform it to being exactly the same as the scaled model would be? Or is this what using rotateMesh() will do?

I'm not entirely sure how the positions in worldspace are different for my two XML files. Each of them loaded the same 3DS file. One imported it at scale 1f (and exported to XML) and the other imported it at scale 17f (and exported to XML). The one that is imported to scale 1f then gets set to scale by .setScale, so all the parts of the model should surely be in the same place?

I know I'm wrong, because my 3D knowledge simply isn't that great. I just don't understand why it's wrong :D

48
Support / Re: Argh! setScale collisions!
« on: May 17, 2008, 03:09:50 pm »
Hurray!

Using the FPS demo as a base, I've been able to create a reproducable test case. I will email it to you.



49
Support / Re: Argh! setScale collisions!
« on: May 17, 2008, 03:00:29 pm »
Phew, okay...

I tried getWorldTransformation() before and after I did setScale and the matrices are different.
Matrix before:
(
   1.0   0.0   0.0   0.0
   0.0   1.0   0.0   0.0
   0.0   0.0   1.0   0.0
   0.0   0.0   0.0   1.0
)

Matrix after:
(
   17.0   0.0   0.0   0.0
   0.0   17.0   0.0   0.0
   0.0   0.0   17.0   0.0
   6.0906405   33.543255   137.59756   1.0
)

Regarding the fragments that disappear. You were right, I was creating the octree before doing the rotatemesh. I have switched this around and the structure looks okay, although the lighting is different. I imagine this is still due to the order in which I am doing things?

50
Support / Re: Argh! setScale collisions!
« on: May 17, 2008, 11:07:25 am »
Firstly, I've grepped for enableLazyTransformations.
The only reference I can find is in my program that generates the XML file.
In my other program which uses collision detection, my code specifically disables lazy transformations before setScale is run. Code is like this:

getWorld().getCamera().setPosition(new SimpleVector(-11, -36, -40));
getWorld().setAmbientLight(50,50,50);
model = getWorld().getObjectByName("model");
model.disableLazyTransformations();
model.setScale(17);

It's possible that lazyTransformations were enabled when the XML file was originally created. Is that likely to cause these problems?

In answer to your other questions:

1) Yes!
This fixes the problem. Collision detection doesn't misfire. However, moving my camera around causes fragments of the model to appear and disappear. I assume this is just a temporary feature of the rotateMesh being applied, so I'm not too worried about it.

2) Let me know whether the above information suggests anything to you. If not, I'll see if I can modify the FPS demo to produce the same effect. I'm not quite sure if it'll be possible though.

51
Support / Re: Argh! setScale collisions!
« on: May 16, 2008, 11:46:20 pm »
I've tried disabling lazy transformations both before and after I set the scale, with no effect.

Unfortunately, my code is all too interconnected for me to be able to provide a test case as I'm using a client/server model with rendering done on a client and collision detection done on a server.
I could send you the two versions of the XML file I'm using. Maybe I've done something silly in constructing them.
I also have the code for the construction of the model itself. But it's abstracted slightly. In pseudo code it looks rather like this:

Loader.loadSceneFromXML(s, state.getWorld());
For all objects in the world:
1) Convert to triangle strips
2) Set collision mode to detecting collision with others and activate optimization
3) Set up octrees

Build world
Generate camera
Set camera position
Get the structure by name (in the world)
SetScale on the structure

<ponder> Maybe build world should come AFTER the scaling?

And to clarify, when I do this, collisions are immediately being detected by camera.checkCameraCollisionEllipsoid even though there are no visible collisions present. In response to this, my camera drifts upwards (which I would expect to happen in my collision system) until the camera elipsoid is (I would guess) more or less exactly reseting on top of the model.
To make it work correctly, all I do is load a different XML file (same model, but with the scale already set) and don't use .setScale. The camera is still in exactly the same location, everything looks identical and collisions are only detected when they ought to be detected.


52
Support / Argh! setScale collisions!
« on: May 16, 2008, 08:52:29 pm »
Okay!

I have a 3DS model of a hollowed out area.

I've imported it at scale 1 and exported it to XML (file1).
I've then taken the same model, imported it at scale 17 and exported it to XML (file 2).

If I open file2, everything behaves as it should. I can move my camera around and checkCameraCollisionEllipsoid produces something sensible when I collide with things.
I can produce exactly the same appearance/view if I import file1 and use .setScale(17) on the resulting model. However, if I set the camera to exactly the same location, checkCameraCollisionEllipsoid continually detects collisions. Even when there's nothing visibly colliding with the camera.

I'm not quite sure why this should happen, am I doing something wrong with setScale? Do I need to do something else after calling it? The only thing that I can think of that might cause this problem is that the original model of file1 is still present, even after calling setScale(17) and only the resulting modification of the model after calling .setScale is visible.

Any clues? It's really hurting my brain :(



53
Bugs / Re: Scaling bug with XML export?
« on: May 14, 2008, 10:31:18 pm »
Ahhhh, I understand.

54
Bugs / Re: Scaling bug with XML export?
« on: May 14, 2008, 09:45:56 pm »
Interestingly, if I load a 3DS model via Loader.load3DS and specify the scale in there, then that scale is reflected in the XML output.

It's ignored if the scale it set via the setScale function of the model object.

55
Bugs / Re: Scaling bug with XML export?
« on: May 11, 2008, 04:47:31 pm »
Cool, I'll just stick with the post loading scaling for now :)

56
Bugs / Scaling bug with XML export?
« on: May 10, 2008, 05:45:13 pm »
Hello,

If I import a model, and then use .setScale on the corresponding Object3D, the scale of a model can be set.
If I export the world using World.toXML(), however, the XML file stores the scale of the original model file, not the scale as set by the .setScale command.

Is this intentional behaviour? I would have expected the exported XML file to reflect the scale set with the .setScale command.

57
Support / Re: Identifying the dummy textures?
« on: May 06, 2008, 08:30:23 pm »
Ah, okay, excellent.

Thanks!

58
Support / Identifying the dummy textures?
« on: May 06, 2008, 08:17:02 pm »
Hello,

Is there any way to determine, in the texture manager, which textures are dummies and which textures have already been loaded? I notice that I can get the current dummy texture, but how can I tell which references in the texture manager were created when I loaded some structure and which point to some actual texture in memory?

I assume it's not sufficient to do an equlity test with the current dummy texture, as they each have different names. I also notice an "isEnabled" function for Textures, but I'm not exactly sure what this represents and when it's set.

Specifically, I'm trying to load a structure from XML and then load the textures that are referenced by the XML document. I don't want to load the textures in advance.



59
Bugs / Re: OutOfMemoryError
« on: May 05, 2008, 10:24:34 pm »
Awesome, thanks.

60
Bugs / Re: OutOfMemoryError
« on: May 03, 2008, 07:02:26 pm »
Ah,

It was easier than I thought to reproduce.
I have emailed the Java source to you.

NB: I can't seem to determine what version of JPCT I'm using. It's either 1.5 or 1.4, but I suspect it's 1.5

Cheers!

Pages: 1 2 3 [4] 5 6