Screenshot Thread

[miceiken]

lol, nice, gief

[Flowerew]

i am finally able to display complete azeroth terrain on my 9600gt \o/

[suicidity]

nice work flow, looks pretty.

[MaiN]

i am finally able to display complete azeroth terrain on my 9600gt \o/

Damn that's quick.
Do you parse WMO/doodads as well?

[paradoxial]

Damn that's quick.
Do you parse WMO/doodads as well?

I'm interested as well, can you zoom in maybe Flowerew.

[suicidity]

@ Main - Doesn't look like it. But it might be because he's zoomed out so far?

I just started working on my visibility checks

[WannaBeProgrammer]

@ Main - Doesn't look like it. But it might be because he's zoomed out so far?

I just started working on my visibility checks

Just a quick question, so i can do reseach about it.
Whats the name on the function you are using to created the line.

[MaiN]

Just a quick question, so i can do reseach about it.
Whats the name on the function you are using to created the line.

The technique is called ray casting or ray tracing.

[suicidity]

If you're talking about the line I draw:
The Battlefield 2 engine (What Battlefield Heroes uses) just implements ID3DXLine; I'm using it for now, but I prefer to use primitives when I use my own functions.

If you're talking about tracing a line in 3d space to the object:
The technique is called ray casting; You can look at D3DXIntersect (D3DX implementation of ray tracing), but any game-engine would have their own implementation somewhere.

Ray Casting casts 1 ray until it hits, Ray Tracing can trace secondary rays.

[WannaBeProgrammer]

+rep to both of you

[Flowerew]

Damn that's quick.
Do you parse WMO/doodads as well?

I'm interested as well, can you zoom in maybe Flowerew.

I did not parse WMOs or doodads in this pass. But adding them lowers the speed to around 14-16 ADTs/s (though i haven't invested any optimization efforts on them yet). In this example I managed remove unecessary vertices like holes/chunks covered by water and rearrange the buffers to finally fit this beast in my vertex buffer. If I would parse them I could probably only load about 400 ADTs in one go before my graphic card surrenders. I will try to upload a pic tomorrow.

[adaephon]

@Flowerew really impressive. You might be interested in looking into graphics level of detail algorithms to reduce the amount of vertices you pass to the buffer when zoomed out. That might allow you to chuck the whole lot on the graphics card at any zoom, without worrying about removing vertices around holes and stuff (or allowing you to add WMOs and doodads.

[Flowerew]

The promised screen (a little closer):



Thanks for the nice feedback, ppl.

@Flowerew really impressive. You might be interested in looking into graphics level of detail algorithms to reduce the amount of vertices you pass to the buffer when zoomed out. That might allow you to chuck the whole lot on the graphics card at any zoom, without worrying about removing vertices around holes and stuff (or allowing you to add WMOs and doodads.

That's probably a thing i'll look into in the future, however the accompaning "i can display it" thing, is just a byproduct of removing data i don't want for navmesh generation. Maybe you want to do it ahead of me, since I'm planning to release the source here at mmowned, after i've cleaned up, commented and make it work on windows as well...maybe today, maybe by the end of the week or so.

I would really like to see others performance results since i don't consider my rig highend (it wasnt even 2-3 years ago). I also have plans to make this thing an exporter to open meshes in modelers like maya/blender, especially for navmeshes to fine tune them manually. So many ideas...we'll see.

[Ryns]

Maybe you want to do it ahead of me, since I'm planning to release the source here at mmowned, after i've cleaned up, commented and make it work on windows as well...maybe today, maybe by the end of the week or so.

I would really like to see others performance results since i don't consider my rig highend (it wasnt even 2-3 years ago).

Really excellent work, I just started parsing out the ADT's myself, but if you're planning to open-source your implementation I can't wait to see it! p.s. no need for a crappy Windows port, i am on Fedora 12 x64 (dual quad core xeon) here.

+Rep

[DrakeFish]

Memory variable that will make WMO's render differently.
Main use of this is to see the real collision of the WMO (the grey one shows detailed collision), as you can see, stormwind top is being rendered because it has an "invisible top".
Note that all those images are rendered by WoW, it's not something made with photoshop.

Information:
1. Normal view, we can't see collision and we do see the textures.
2. Collision view, we don't see the visual WMO model, what we see is the whole collision.
3. No render, doesn't show the WMO.
4. Visible Collision, it shows the collidable surface.
5. Visible only, it shows the non-collidable visible surface.
6. Non-Visible Collision, it shows the invisible collidable surface only.

The normal view is made by the blue and green, with textures on it.
The grey surface is made by the green and red surfaces together, because it's the collision.