My eqview program

[jbb]

A new improved version of my eqg zone viewer is available
here (about 650K)

This is a binary release for windows d3d9. I'll release the source code later on today when I've fixed a couple of issues.

This only works with the EQG file Omens of War zones but I believe it works with them all now.
It now has added mouse control, works with all the zones, and is a bit faster.
Please read the README in the zip file

I hope nobody minds me posting this on here. It's not openeq but it might be of interest to some of the people who are interested in that, and it's open source (or at least will be when I fix the source later today... ) so might be helpful to people trying to draw the same things.

My todo list for this includes:
There are some placable items which don't seem to belong.
Drawing more than just the base textures so it looks a lot better.
Getting collision detection working so you can walk instead of fly.
Getting an opengl renderer working then "Port" to linux
Getting old style zones working too


See also: http://www.fx2100.com/ for more information (maybe)

[jbb]

Just wondering if anyone has had any sucess with this?
I've seen a few downloads from my webserver so someone must have tried it

[Speedz]

works great, good job

[jbb]

Anyone know anything about how to draw "normal map textures"?
Can't seem to make it work at all well.


(Also posted on my small forum for my engine at www.fx2100.com if it's more on-topic there)

[daeken_bb]

Originally Posted by jbb

Anyone know anything about how to draw "normal map textures"?
Can't seem to make it work at all well.


(Also posted on my small forum for my engine at www.fx2100.com if it's more on-topic there)

I personally have no problem with you posting stuff about EQView on the forums here. I think it'd be valuable for OpenEQ to have various reference loaders and renderers

[jbb]

I spent some time yesterday adding code to use the normal textures. It was a sucess in that I can now draw the normal textures as well as the diffuse textures. But it looked horribly wrong.

After some reading today I've figured out that it's much more complicated that I thought. I need to transform the light vector into "normal" space for each triangle each time I draw it. Rather than make my rendering loop do this I'm going to use a vertex shader I think.

Directx9 emulates vertex shaders (but not pixel shaders) in software on cards that don't support it in hardware so this should work on any card.... Does anyone know if opengl does anything similar? Or are "real" vertex shaders (vertex programs on opengl?) required in order to use them?

[Windcatcher]

I can't speak for the new files, but when dealing with WLD (or what you plan on turning into WLD) in OpenGL you have to set it to use emissive lighting. This wouldn't be so bad except for the problem that, when dealing with alpha transparency, OpenGL likes to throw out the alpha value when you use the glColor4ub() command to set the color. My solution is to cache the last-set alpha value and switch to normal lighting mode with glColorMaterial(GL_FRONT,GL_AMBIENT_AND_DIFFUSE) to change it whenever I encounter a triangle with a different alpha value, then change back with glColorMaterial(GL_FRONT,GL_EMISSION). Generally the only three alpha values you ever run across are 0, 128, and 255, so it's not too bad, especially if you do a two-pass rendering process like I do where you first render only the triangles with alpha=255 and then render anything not 255 in the second pass. I have to warn you though that glColorMaterial is very expensive to use in terms of time (according to the docs on msdn) and must be used as sparingly as possible.

[jbb]

At the moment I have d3d lighting disabled and am just drawing the textures without lighting. I don't have any information on the location or nature of light sources in the new files so can't do proper lighting at this time although I think it likely there is some kind of lighting information in the .lit (?) files. Not sure.

I'm trying to get the bump map stuff working first. To do that I need to take the normal texture, and the vector to the light source and calculate the dot product at each pixel. And then use the resulting texture to modulate the main texture. D3D can do this using the D3DTOP_DOTPRODUCT3 texture combiner mode. I believe that opengl has a similar extension. The problem I'm having is that the lighting vector to apply is the vector of the light source in *texture space* so I have to transform the light vector for every polygon. And I don't yet understand the math well enough to do this. Working on it though... Lot of reading to do.

On the subject of alpha, I've only seen 0 and 255 in the "new" zones which makes it a bit easier as no sorting is required for that, just use an alpha mask. There could be some other values in files I've not yet looked at I suppose.

[daeken_bb]

Originally Posted by jbb

At the moment I have d3d lighting disabled and am just drawing the textures without lighting. I don't have any information on the location or nature of light sources in the new files so can't do proper lighting at this time although I think it likely there is some kind of lighting information in the .lit (?) files. Not sure.

I'm trying to get the bump map stuff working first. To do that I need to take the normal texture, and the vector to the light source and calculate the dot product at each pixel. And then use the resulting texture to modulate the main texture. D3D can do this using the D3DTOP_DOTPRODUCT3 texture combiner mode. I believe that opengl has a similar extension. The problem I'm having is that the lighting vector to apply is the vector of the light source in *texture space* so I have to transform the light vector for every polygon. And I don't yet understand the math well enough to do this. Working on it though... Lot of reading to do.

On the subject of alpha, I've only seen 0 and 255 in the "new" zones which makes it a bit easier as no sorting is required for that, just use an alpha mask. There could be some other values in files I've not yet looked at I suppose.

It might be easier to just use a bump-mapping shader for this.
Also, I suggest you check out NeHe's bump mapping tutorial... it's somewhere at http://nehe.gamedev.net

Their examples are all for OpenGL, but the concepts should map directly to DX.

[jbb]

Well, I *believe* that the normal textures have per-pixel normal vectors with the (x, y, z) components of the packed into the (r, g, b) components of the texture bitmap using

r = 128 + 127 * x; // Where x varies from -1.0 to 1.0
And the same for the g and b components.

This is farily standard for this kind of thing from what I can gather. The simple bump mapping requires something different to be stored in the "bump" bitmaps.

And it's very easy to set up the rendering states to work with this.
The problem is that I need to calculate the light direction vector in the same coordinate system as the normal vectors in each bitmap. I think you'd have to do the same with the simple bump mapping system too. And it's that that I'm having trouble getting my head around. It's too many years since I did any real mathematics As I said, will just take some time. I could probaby borrow a funtion from somewhere but I want to understand it.

[jbb]

Hmm it looks quite complicated to do this properly so instead I'm looking at writing a renderer using ogre3d which already handles this and a whole lot of other things. Hopefully I'll have something to show in a few hours. I got it drawing a cube so far !

[Belfedia]

Link is dead and site too :/

[jbb]

Sorry, yes.
I can put it back up later on today if there is any interest.

[Zarbula]

I have an interest in this program, if it could be sent to my email:

nandesu@nandesu.org

Thank you

[Belfedia]

I dislike start eq, for see a zone, your program is very usefull, where we can download it ?