Placeable object help please.

[daeken_bb]

I need a bit of help with the .zon file format. I have placeable objects rendering perfectly, but the scaling is way off. I'm currently using the scaling variable as a float and scaling x and y by this. Is that not the proper way to do it? If not, please tell me how to scale the objects :)

Happy Hacking,
Lord Daeken M. BlackBlade
(Cody Brocious)

[jbb]

I'll look what I did in my renderer where it seemed about right.
But it's on my other computer which is currently in pieces... When I put it back together I'll have a look. In an hour or two maybe.

[daeken_bb]

I'll look what I did in my renderer where it seemed about right.
But it's on my other computer which is currently in pieces... When I put it back together I'll have a look. In an hour or two maybe.
Great, thanks :D

[jbb]

Ok, my other PC isn't connected to the network at the moment so I'll have to retype some of this here... If you can't get it to work I'll be able to post my code later on probably.

I have this structure for placable objects

struct Object
{
long id;
long offset;
float x, y, z;
float rx, ry, rz;
float scale;
}

You're probably loading this already.
x, y, z are the locations in the world of the object and rx, ry, and rz are the rotations (In radians I guess, not sure) and scale is the scaling factor on the size of the object.

To draw it I have this code (which is using D3D vector objects and the vector math library)

D3DMATRIX tMat, rxMat, ryMat, rzMat;


D3DXMatrixTranslation(&tMat, mesh->x, mesh->y, mesh-z);

// Hmm, wierd swapping of coordinates below, can't remember why
D3DXMatrixRotationX(&rxMat, mesh->rz);
D3DXMatrixRotationY(&rxMat, mesh->ry);
D3DXMatrixRotationZ(&rxMat, mesh->rx);

// These are vector multiplies that the direct 3d library provides in their c++ classes
matWorld = mesh->scale * rzMat * ryMat * rxMat;
matWorld = matWorld * tMat;

m_pD3DDevice->SetTransform(D3DTS_WORLD, &matWorld);

So yes, basically I scale the object (in x y and z), then rotate it and then move it to it's place in the world. (I think the order of the matrix multiplies means I do it in this order)

Maybe you've got the order of these operations wrong so you're trying to scale an object which isn't at the coordinate system origin or something.

Also, the main terrain object has x, y, z coordinates and the placable objects are all positioned relative to the world object.... So you either need to add the x, y, z coordinates of the objects to those of the landscape model or do what I did and zero out the x, y, z coordinates of the terrain model before drawing it so that the placeable objects are in the same system.

Well, I'll post the actual code when I'm able to but this did seem to work for me.

[jbb]

The full source is here:
http://eqengine.fx2100.com/eqengine_src.zip

It's windows, c++ and direct3d 9 but hopefull it will make some sense.

I don't know if this version even builds at all but hopefully it's not too far from the one that did.

[daeken_bb]

This is really starting to bug the hell out of me now lol.

It seems that I'm not only doing the scaling properly, but also the rotation seems waaaaay off. I tried converting radians into degrees, but that just made the problem worse heh.

I'm about ready to call sony up and ask for a bit of help on this ;)

Here's the code for the placeable object draw routine, in case this is where the problem is:

for(j = 0; j < this->model_data->plac_count; ++j) {
plac = this->model_data->placeable[j];
glPushMatrix();
glLoadIdentity();

glRotatef(270, 1.0, 0.0, 0.0);
glRotatef(rot[1], 1.0, 0.0, 0.0);
glRotatef(rot[0], 0.0, 0.0, 1.0);

glScalef(plac->scale, plac->scale, plac->scale);

glTranslatef(trans[0], trans[1], trans[2]);

glTranslatef(plac->x, plac->y, plac->z);

glRotatef(plac->rx, 1.0f, 0.0f, 0.0f);
glRotatef(plac->ry, 0.0f, 1.0f, 0.0f);
glRotatef(plac->rz, 0.0f, 0.0f, 1.0f);

glCallList(this->model_lists[plac->model]);

glPopMatrix();
}


And here's the code for the placeable object placement/rotation loader from zon.cpp:

for(i = 0; i < hdr->obj_count; ++i) {
plac = (zon_placeable *) buffer;

this->model_data.placeable[i] = new Placeable;

this->model_data.placeable[i]->x = plac->x;
this->model_data.placeable[i]->y = plac->y;
this->model_data.placeable[i]->z = plac->z;

this->model_data.placeable[i]->rx = plac->rx;
this->model_data.placeable[i]->ry = plac->ry;
this->model_data.placeable[i]->rz = plac->rz;

this->model_data.placeable[i]->scale = plac->scale;
this->model_data.placeable[i]->model = 0;

zon_tmp = zon_orig + plac->loc;
while(zon_tmp[strlen((char *) zon_tmp) - 4] != '.')
zon_tmp += strlen((char *) zon_tmp) + 1;
for(j = 0; j < this->model_data.model_count; ++j) {
if(!strcmp(model_names[j], (char *) zon_tmp)) {
this->model_data.placeable[i]->model = j;
break;
}
}

buffer += sizeof(zon_placeable);
}


If you see anything obviously wrong, please let me know hehe.

Happy Hacking,
Lord Daeken M. BlackBlade
(Cody Brocious)

[jbb]

I don't see anything immediatly wrong. The only thing I can think of immediately is are you locating the start of the array of objects in the zone file properly?

Is it drawing the objects in what look like the right places?
Even if they are the wrong size & orientation?

You can usually spot things like likes of torches down corridors in some of the zones.

[daeken_bb]

I don't see anything immediatly wrong. The only thing I can think of immediately is are you locating the start of the array of objects in the zone file properly?

Is it drawing the objects in what look like the right places?
Even if they are the wrong size & orientation?

You can usually spot things like likes of torches down corridors in some of the zones.

Yea, they objects are definitely where they're supposed to be, it's just that the scaling and rotation is waaay off it seems.

[jbb]

Hmm,
maybe if you print out the scaling, location and rotation vectors of some of the objects inside the drawing loop then I could compare them with what I get.

Then at least you might be able to establish if the problem is in the loading or the drawing code.

Probably not going to be able to do that with my code until tomorrow though.

[daeken_bb]

Oh bloody 'ell... I just realized some stuff...

1) I've been drawing 2 zone meshes (yes, i feel stupid)
2) I've never offset the transformations (which is ok because I haven't been following the transformation for the zone mesh, i guess)

So, now that I feel like a total asshat...
http://home.archshadow.com/~daeken/draniksscar.txt
http://home.archshadow.com/~daeken/anguish.txt
http://home.archshadow.com/~daeken/wallofslaughter.txt
http://home.archshadow.com/~daeken/riftseekers.txt

[jbb]

Sorry I'm not going to have time to look at this tonight, but i'll see what mine is outputting tomorrow morning. Yours looks like it is probably right though.

[jbb]

You don't have any additional rotations and scaling in the display list do you?

[daeken_bb]

Sorry I'm not going to have time to look at this tonight, but i'll see what mine is outputting tomorrow morning. Yours looks like it is probably right though.

You don't have any additional rotations and scaling in the display list do you?

Thanks... whenever you have time that's fine :D

No, the display list doesn't have anything aside from the triangle drawing and tex coords.

[daeken_bb]

Well, I have the doors in anguish placed properly, but they're the only objects showing up in the right place with the right rotation lol:

http://home.archshadow.com/~daeken/plac1.jpg
http://home.archshadow.com/~daeken/plac2.jpg
http://home.archshadow.com/~daeken/plac3.jpg

I'm making some progress, but it's still not quite right.

[jbb]

Good morning!
I've put my dump for dranksscar at
http://eqengine.fx2100.com/output.txt

The position data looks the same as yours.

However my renderer seems to be rather wrong in that zone too.
I need to do some more checking.

Edit: I rewrote this post as first of all I though mine was working but it's not. Perhaps we've misinterpreted the data structure in some way. It looks right, but maybe those aren't just x, y, z rotations,

[daeken_bb]

Good morning!
I've put my dump for dranksscar at
http://eqengine.fx2100.com/output.txt

The position data looks the same as yours.

However my renderer seems to be rather wrong in that zone too.
I need to do some more checking.

Edit: I rewrote this post as first of all I though mine was working but it's not. Perhaps we've misinterpreted the data structure in some way. It looks right, but maybe those aren't just x, y, z rotations,

Have you thought that maybe you use the unknown for something? hmm...

[jbb]

Yeah I'm going to spend some time on this afternoon.
Hopefully it should be possible to figure out what's wrong, but first I need to get my renderer code working properly again

[daeken_bb]

Yeah I'm going to spend some time on this afternoon.
Hopefully it should be possible to figure out what's wrong, but first I need to get my renderer code working properly again

Ok :)

In the mean time I'm going to debug my new file loader and then implement wld support hehe

If you need any help, just post... gmail notifies me of new posts hehe

[jbb]

This is annoying me now :
I have this
http://eqengine.fx2100.com/view1.JPG
which doesn't look too bad. Much of that geometry is placable objects placed right next to the main world object. But there are some objects in mid-air.

And then there is this:

http://eqengine.fx2100.com/view2.JPG
Where the doors seem to be exactly 90degrees in one axis out. They are facing the middle of the room, not across the doorway.
Maybe I need to rotate one of my axis by 90degrees.

[daeken_bb]

Awesome... good work :)

You're definitely closer than I am hehe.
Did the unknown value have anything to do with it?

[jbb]

Which is the unknown value?

I've pretty much got the same basic idea as you I think.
I've just been playing about with swapping around the axes for rotations until it looks about right.

Still working on it but rapidly getting annoyed that it's close but not quite there

[daeken_bb]

Which is the unknown value?

I've pretty much got the same basic idea as you I think.
I've just been playing about with swapping around the axes for rotations until it looks about right.

Still working on it but rapidly getting annoyed that it's close but not quite there

The unknown value is the first in the struct... before the model name offset.

Yea, I know the feeling for sure... that's practically all i've been doing for the last 3 or 4 days lol.

Good luck, and I hope you figure it out hehe

[jbb]

This is strange.

Most of Anguish looks fine but there are a number of objects in the sky which don't seem to belong. Now Anguish is an "indoor" zone so it's entirely possible that they are there on live too and just not visible either because you can't get to where they are, or they are hidden for some reason with fog or clipping plane or the shaders don't draw them or something.

Sadly I can't get to Anguish on live as it's a keyed zone I don't have the key for.... But the zones I can get to look pretty flawless. It can be very hard indeed to match up what I can see with what I can see on live because it looks so much better on live with the bump maps, proper lighting and fog etc. But the objects do seem to be in the right place most of the time.

Are you able to post a full copy of your code and I can see if I can get it working on my machine and at least find out where it looks different to my code and what causes thouse differences?

[daeken_bb]

This is strange.

Most of Anguish looks fine but there are a number of objects in the sky which don't seem to belong. Now Anguish is an "indoor" zone so it's entirely possible that they are there on live too and just not visible either because you can't get to where they are, or they are hidden for some reason with fog or clipping plane or the shaders don't draw them or something.

Sadly I can't get to Anguish on live as it's a keyed zone I don't have the key for.... But the zones I can get to look pretty flawless. It can be very hard indeed to match up what I can see with what I can see on live because it looks so much better on live with the bump maps, proper lighting and fog etc. But the objects do seem to be in the right place most of the time.

Are you able to post a full copy of your code and I can see if I can get it working on my machine and at least find out where it looks different to my code and what causes thouse differences?

Source is available at http://home.archshadow.com/~daeken/openeq.tar.bz2
It's slow as hell right now because I'm using an octree for drawing but I'm not actually culling yet (I commented it out for the tarball since it's buggy as fuck) but it'll work

Thanks for giving it a shot... hopefully you'll be more successful than I ;)

[jbb]

Hmm yes it's for unix.
First task it to port to windows then as my only linux machine is a server only without even a display of any kind.

[daeken_bb]

Hmm yes it's for unix.
First task it to port to windows then as my only linux machine is a server only without even a display of any kind.

It _should_ be no trouble to port it to windows. The only major change should be changing the main() function to WinMain or whatever that is. Everything else is written to be portable (binary modes, SDL, OpenGL, etc)

[jbb]

It's lots of small stuff.
Like the opengl headers require windows.h to be installed first.
And I've got to install SDL etc. first.

Working on it

[jbb]

Compiled and linked with about 20 changes to the source. Mostly adding #include <windows> in appropriate places. But now it's crashing when I try to load anguish on the line starting with !strcmp the this->model_data.models[j]->tex[i]-> is null so when it tries to get the filename it's crashing. Looking at it...

tex_tmp = 1;
for(i = 0; i < this->model_data.models[j]->tex_count; ++i) {
for(k = 0; k < this->model_data.zone_model->tex_count; ++k) {
if((!this->model_data.zone_model->tex[k]->filename && !this->model_data.models[j]->tex[i]->filename) ||
(this->model_data.zone_model->tex[k]->filename &&
this->model_data.models[j]->tex[i]->filename &&
!strcmp(this->model_data.zone_model->tex[k]->filename, this->model_data.models[j]->tex[i]->filename))) {
tex_tmp = 0;
break;
}
}

Edit: Actually it's not null, it's *uninitialized*. j is 212 when this happens

[jbb]

I'll narrow this down some more.
model[212] has a tex_count of 1
And it's tex memory points to a valid structure, but the filename member of that structure is not initialized.
Can't figure out why just yet but I'm looking. I mention it here in case this means anything to you.

[daeken_bb]

I'll narrow this down some more.
model[212] has a tex_count of 1
And it's tex memory points to a valid structure, but the filename member of that structure is not initialized.
Can't figure out why just yet but I'm looking. I mention it here in case this means anything to you.

What is probably happening is that the .TER material list loader is acting up again and not setting the filename properly. I'd add some printf()s to do some debugging

[jbb]

I got it to ignore items 212 and 213 in the list, both of which caused problems and now I get this :

http://eqengine.fx2100.com/openeq1.jpg

Which is big progress but missing all the placable items.
I like your mouse control by the way.... Got to get that working on mine

[daeken_bb]

Ok, first things first, comment out line 127 of draw.cpp (glEnable(GL_CULL_FACE)) as it causes walls to disappear on new-style zones (fucking sony doesn't organize their vertices properly lol)

Second, it's quite possible I broke placeable objects, and I'm checking into it now. I've been changing the draw code a lot while playing with the octree, so it's _highly_ probable I did something stupid ;)

I'll update you in a moment.

[daeken_bb]

Ok, placeable objects work (well, as much as they've ever worked in OpenEQ lol) here.

I wonder if your video card doesn't support OpenGL display lists or something simple like that...

What video card are you using?

[jbb]

I'm using a Geforce FX9500XT which does support display lists for sure. I'll try it on my laptop (Radeon mobility 9800) and see if it works on there.

[daeken_bb]

I'm using a Geforce FX9500XT which does support display lists for sure. I'll try it on my laptop (Radeon mobility 9800) and see if it works on there.

Lol, yea, I'd say so... I was kinda worried that you were using an ANCIENT (it'd have to be to not support display lists in opengl) card for dev, but instead you beat the shit out of my card, a measly geforce 4 mx440 Lol.

Anyway, hopefully it won't work on the radeon... it's a lot harder to debug hardware-specific bugs ;)

[jbb]

No, doesn't work on the laptop either.
Well, that's to say it does work in exactly the same way.
I'll do a bit of debugging. Looks like a windows portability issue maybe.

[jbb]

From Draw::InitLists

this->model_lists = new GLuint[this->model_data->model_count];

for(j = 0; j < this->model_data->model_count; ++j) {
glNewList(this->model_lists[j], GL_COMPILE);

This looks suspect to me.
glNewList's first paramater is an integer 'name' you pass in to tell it which display list to use. But you're passing in an uninitialized value as far as I can tell. Also my reference implies that you need to use glGenLists to reserve the "names" you want to use for your display lists (And says that it might work if you dont but won't be reliable on all hardware/driver combinations)

Unless I've missed something.

[daeken_bb]

From Draw::InitLists

this->model_lists = new GLuint[this->model_data->model_count];

for(j = 0; j < this->model_data->model_count; ++j) {
glNewList(this->model_lists[j], GL_COMPILE);

This looks suspect to me.
glNewList's first paramater is an integer 'name' you pass in to tell it which display list to use. But you're passing in an uninitialized value as far as I can tell. Also my reference implies that you need to use glGenLists to reserve the "names" you want to use for your display lists (And says that it might work if you dont but won't be reliable on all hardware/driver combinations)

Unless I've missed something.

Ack... I forgot all about that...

Add this->model_lists[j] = glGenLists(1); before the glNewList() line.

I rewrote that code at 4am yesterday and I kinda looked over that... thanks :)

[jbb]

I also changed it to say
for(j = 0; j < this->model_data->model_count; ++j) {
model_lists[j] = j;
glNewList(this->model_lists[j], GL_COMPILE);
and now I get the placable objects. Although they are all in the wrong places :)

Now I can look at the actual problem you were having... After I've eaten my pizza!

[daeken_bb]

I also changed it to say
for(j = 0; j < this->model_data->model_count; ++j) {
model_lists[j] = j;
glNewList(this->model_lists[j], GL_COMPILE);
and now I get the placable objects. Although they are all in the wrong places :)

Now I can look at the actual problem you were having... After I've eaten my pizza!

Fantastic :)

I do suggest, however, that you use glGenLists() as it could cause problems with some things if you don't.

Either way, thanks for taking a look... hopefully you'll find something hehe

[jbb]

Unless I'm mistaken you're drawing the main zone object in a different way from the placable objects and not taking into account that the main zone object may also be rotated. I seem to have a rotation on my main zone object too in my renderer, maybe that's the difference unless I've missed something in your code.

I'll try to "hack" in a quick additional rotation to undo the rotation of the main object to confirm that theory.

[jbb]

Er, no sorry. My renderer also ignores the rotation on the main object too.

[jbb]

I'm well confused now.

The good news is that I've stepped through your code and my code with a breakpoint on the code which draws each object and the (x, y, z) and (rx, ry, rz) is identical in every case. You're trying to draw *exactly* the same thing right down to the low level drawing code.

The bad news is that it looks right on mine and wrong on yours still.

The only thing I can think of is that opengl has a right handed coordinate system and direct 3d a left handed (by default). Maybe it's something to do with that.

My brain hurts now so I'm taking a break.

[daeken_bb]

I'm well confused now.

The good news is that I've stepped through your code and my code with a breakpoint on the code which draws each object and the (x, y, z) and (rx, ry, rz) is identical in every case. You're trying to draw *exactly* the same thing right down to the low level drawing code.

The bad news is that it looks right on mine and wrong on yours still.

The only thing I can think of is that opengl has a right handed coordinate system and direct 3d a left handed (by default). Maybe it's something to do with that.

My brain hurts now so I'm taking a break.

Well, at least we now know that there's nothing completely off-the-wall happening here :)

Thanks for giving it a shot and giving me some confirmation that I'm not doing something horrendously stupid ;)

I'll look into a bit more later today, but right now I'm trying to finish frustum culling... it's not cooperating lol

[jbb]

Will look at this again when I've had some more sleep.
I must be missing something obvious.

[daeken_bb]

Will look at this again when I've had some more sleep.
I must be missing something obvious.

Thanks for all the help :)
Talking with windcatcher on irc right now about this... m'be we can work it out hehe

[jbb]

I'm not quite so sure about having the same data any more.
One of us is drawing 695 objects and the other 665.
I only compared the first 10 or so and assumed that if they were were same they all were. But maybe not.

[jbb]

any progress? Not had time to look today, hopefull can tomorrow.

[daeken_bb]

any progress? Not had time to look today, hopefull can tomorrow.

Nope. Windcatcher said that the problem with the placeable object drawing was probably our camera code, so he convinced me to switch over to gluLookAt() and I haven't been able to get our movement code working properly since haha. So I'm probably going to switch back to the old style in a moment, as this is really frustrating as-is :P

[jbb]

That sounds plausable.

[daeken_bb]

That sounds plausable.

That wasn't the problem. I'm sure of that now (after having seen what it looked like when rendering with gluLookAt), but it was a possibility then. I finally realized that I'm essentially doing what gluLookAt() does hehe.

Anyway, I'm getting closer. Torches appear perfectly now, so that's pretty cool. I think the problem is with the X and Y axes, so I'm looking into that.

[jbb]

Any progress?
I'm going to have another look at this now, so let me know if you solved it :)

[daeken_bb]

Any progress?
I'm going to have another look at this now, so let me know if you solved it :)

Nope, I've been working on reverse-engineering character models, and making a ton of progress :D