How to draw a cube from .map coordinates?

(Shaderman) #1

Hi.

I just wondered how the Q3 engine or Radiant draw a cube from the coordinates stored in a .map file like this:

( 0 128 128 ) ( 0 0 128 ) ( 0 0 64 ) common/caulk 0 0 0 0.500000 0.500000 0 4 0
( 128 128 128 ) ( 0 128 128 ) ( 0 128 64 ) common/caulk 0 0 0 0.500000 0.500000 0 4 0
( 128 0 128 ) ( 128 128 128 ) ( 128 128 64 ) common/caulk 0 0 0 0.500000 0.500000 0 4 0
( 0 0 128 ) ( 128 0 128 ) ( 128 0 64 ) common/caulk 0 0 0 0.500000 0.500000 0 4 0
( 0 0 128 ) ( 0 128 128 ) ( 128 128 128 ) common/caulk 0 0 0 0.500000 0.500000 0 4 0
( 128 128 0 ) ( 0 128 0 ) ( 0 0 0 ) common/caulk 0 0 0 0.500000 0.500000 0 4 0

Here’s the cube shown in Radiant:

After reading spog’s map definitions and these inofficial Quake specs I understand that the cube is built from planes.

There are 6 rows describing the brush in the .map file (one row for each plane). That’s the part I understand.

But I don’t understand how a rectangular cube is drawn from those planes now. I know that the engine draws triangles but how is the point 128,0,0 calculated for example? It isn’t listed in the .map file but this point/corner of the cube is drawn.

I hope you get what I don’t understand and can explain me how it works :smiley:

Thanks,

Shaderman

(carnage) #2

where the planes cross they create an edge so you get corners but the corners dont have to be the vertex value stored

(Shaderman) #3

Thanks for your answer carnage that’s what I thought, too. But I’d like to understand how this edge is calculated from the given points (how those missing corners are calculated). Is there a keyword (maybe a OpenGL function doing this calculation) I could search for?

Shaderman

(kamikazee) #4

This is the mathematical method:

Eric W. Weisstein. “Plane-Plane Intersection.” From MathWorld–A Wolfram Web Resource. http://mathworld.wolfram.com/Plane-PlaneIntersection.html

This may be implemented in OpenGL allready, but I haven’t got a clue how it’s called.

(Shaderman) #5

Thanks kamikazee, this one is interesting. But should this really be the way a 3d game engine (or GPU) calculates every single (non VISible and then visible) object before it’s shown on the screen every n frames/second? Overkill? I think there must be a much simpler way because all of the given points seem to describe planes but represent corners of the cube at the same time. I tried to find the solution in the Radiant code but didn’t find anything yet in thousands lines of code :confused: What do you think about the fact that all given points are corners at the same time?

(carnage) #6

remember that when maps are compile they become bsp and its likely that the way planes are stored will change compleatly… in fact im pretty sure they do otherwise you would not be able to get a single plane in the game everything would need volume

search for the bsp format… if you find planes vertices being store then it is storeing the corner values of the planes

(SCDS_reyalP) #7

OpenGL works with triangles for drawing, and knows nothing of brushes. Hence the engine and editor also use triangles for drawing. The engine works with brushes only for collision detection. The compiler takes the brushsides and turns them into drawsurfs. If you can read C, you can find all this in the q3map2 source code. You might start with bsp.c:ProcessModels or or surface.c:ClipSidesIntoTree (both in GtkRadiant/tools/quake3/q3map2/)

(Shaderman) #8

Thanks for your answers! I din’t find the time yet to read (and understand :moo:) the the q3map2 source (thanks for pointing me to these starting points SCDS_reyalP). I thought it might be easier to find something in the Radiant sources (for example the drag vertices - v - function) than looking at the q3map2 code which builds the bsp. Radiant is able to draw brushes (something like: open a .map file … parse it … display it) and I think this way is easier to find and understand for and unskilled programmer like me :slight_smile: Any hints where I could start looking at the code in Radiant?

Thanks.

Shaderman

(seven_dc) #9

I though this same question myself. Then I just gave up and made ASE loader. It has the vertex data allready calculated. Only thing is that I have to run q3map2 twice .

  1. map -> bsp
  2. bsp -> ASE

Lovely Wendie

(SCDS_reyalP) #10

No, I picked q3map2 because I’ve spent a bit more time digging around that than radiant. It’s also smaller, and in vanilla C. If I were to try to find it in radiant, I would start with the rendering code and work backwards. Obviously, radiant does the same brush->rendered triangles transformation somewhere.

(Shaderman) #11

Your right SCDS_reyalP, the q3map2 code is much easier to read (especially with some comments in the code) than the Radiant code. I don’t have too much time at the moment but after spending some time, I think I’m close to it now :moo:

A second way I tried is to find something useful on the internet. I thought that I can’t be the first one having this question and searched some game development forums. That’s what I found if someone else should be interested:

The same question I had asked:


And this one is very interesting because someone explains the mathematical method kamikazee posted above:

Now that I have some information, I’ll try to write a small piece of software (maybe with JOGL - Java OpenGL) to display a Q3 style map (without shaders, lights, models and all this extra stuff).

Shaderman