Map Editor & Display Lists?

why arn't you using VertexArrays, it would probably be faster as your data isn't static.

EDIT:

Quote:

the reason I tend to use displaylists is that i can use intermediate rendering methods so i can adjust the data layout of the objects to editing purpose instead of rendering thus making it easier to proceed with writing the editor

I personally don't see that as a good enough reason to use immediate mode. if you are writing an editor your data will most likely be stored in some kind of implementation data structure, not in immediate mode primitive types.

what you can do is "fake" immediate mode by writing a rendering backend to provide glVertex like interface but run Vertex Arrays or VBO's in the back

eg.
usage would be something like this:

Render *gl = new Render();gl->AddVertex(-1, 0, 0);gl->AddVertex( 1, 0, 0);gl->AddVertex( 0, 1.5f, 0);gl->SetRenderMode( TRIANGLES );gl->FlushData();

well
with vertex arrays i have to layout my datamanagement to arrays

here i can use linked lists which makes handle the objects a lot easier

using arrays and working with indices can be a pain in the ass

imagine you have a polygon split it or split an edge

in a linked list you just inset a vertex between the edge's vertices
with arrays you need to update indices ...

@silvermace: imagine a cube with 6 faces each with a different texture
you have 8 vertices but 6*4 = 24 uv coordinates how could you implement this with arrays without storing vertices twice

indexed lists won t work here as far as i know since you can t defer seperate indexed lists once for vertex data one for uv coordinates one for normals


or is there a extension that i don t know of


another pro for display lists is i could store the list indizes outside the objects in a seperate list and update all 2d views with a single to glCallLists(m_iListBase,m_iListCount);


btw can you store vertex arrays in displaylists?

Hi, Bas. Long time, no see [smile].

You could use display lists for very static objects, like detail models, that the user doesn't change very often, if at all. However, if you have an object like a brush, think about how long it would take to rebuild the display list if you had to do it every time the user changed the position of a single vertex. For these highly dynamic objects, you should probably still use vertex arrays and glDrawElements. Perhaps VBOs might be able to help? You could still put the geometry on the graphics card, like you can with a display list, but you would still be able to access it very easily.

You might need to look to other areas to improve performance. You could use frustum culling to make sure that you're not rendering unnecessary objects the user can't actually see. This can dramatically speed things up. Perhaps for objects with very, very high polygon counts, you could have bounding box representations of them when they aren't selected, and the actual object when it was selected. 3ds max does this when you move the viewpoint, and you have high-polygon objects in the scene. It renders them as simple bounding boxes for the duration of the movement, making viewpoint movement very smooth, then renders them properly when you stop moving the viewpoint.

hi insanity hows you editor coming along?

as you see i restarted mine again and i lack the time to finish any of my projects *damn university*

*back to topic*
i thought about this, i could use displaylists to render unmodified objects and everytime i select it and change it i use normal rendering

i never realized that 3dsmax renders the bbox only when moving objects
although i doubt that this will be usefull in a mapeditor because i need to be able to adjust the position of the selected scenery otherwise it would be a little bit difficult to move walls around

Ok I will go with Display Lists for now and maybe keep my data managing compatible with vertex arrays for the case that i need to improve performance further more

btw i had a look at gtk radiant and q3 radiant they use displaylists as well

Display lists are fine. You won't update your viewport often anyway (only if an object is being altered in some way or on camera changes). My editor has an average frame-rate of about 4.5 renders per second so as long as a single frame renders in less than 100ms everything will appear smooth.
Don't optimise editor rendering code unless the output seems to be sloppy. It's just not worth the trouble.

Cheers,
Pat

yeah

the next step is to get the editing functions to work properly

once this is done i guess it should be easier to make visible progress

Quote:

Original post by darookie Display lists are fine. You won't update your viewport often anyway (only if an object is being altered in some way or on camera changes). My editor has an average frame-rate of about 4.5 renders per second so as long as a single frame renders in less than 100ms everything will appear smooth. Don't optimise editor rendering code unless the output seems to be sloppy. It's just not worth the trouble. Cheers, Pat

Well, unless you're sharing rendering code between the engine and the editor - which is a very smart thing to do, as it conforms to the practice of reusability - optimization of one will automatically have the other optimized the same.

i don t share the code with the engine because some features i want to implement in the editor require some really flexible datastructures
e.g.: terrain meshes with varying cell(2 triangles) count per row and per column

designing a renderer for the engine that renders the terrain meshes that way isn t a elegant solution

the editor has 2 output formats one for the level project and once with some optimizations which will be used in the engine

so it s not really possible to write reuseable render code for both projects

on the other hand the artist gains some level of freedom and comfort for levelediting

Quote:

Original post by Basiror hi insanity hows you editor coming along? as you see i restarted mine again and i lack the time to finish any of my projects *damn university*

I know what you mean. I've had a ton of university work, and it's really bitten into the time I have to code. I'm back working on my editor though, after a lengthy interval where I went back to doing demos and things. I'm coding it up for an unnamed external project. It's been renamed Fusion, and it's now part of a group of tools (there's also a scripting system, a WYSIWYG material editor, and one or two other things that might be plugins, and might be standalone apps, like terrain systems).

However, much of this is on paper at the moment [grin]

I am still thinking about how I will implement my primitives

i thought about this

terrain meshes:
- contains a linked list of batches
each batch contains either 1 or 2 triangles and a index of the vertex it used

- the vertices are stored in a array which reserves 50 vertices when you create it or m_iVertices when you load it from a file

- the reason i want to use this solution for meshes is that i don t want to stick with x*y sized meshes + i want to flip the diagonal of the triangles on demand from southwest to north east or northwest to southeast



brushes:
- a list of faces
- each face contains a list of vertices and a plane
- when you alter the size of the bbox of the brush i just move the planes
and rebuild the brush if the new brush is solid i replace the old one

+ add a copy of the old one to the undo list

but i want to include vertex transformations as well
in radiant editors you can select a vertex move it

the editor checks if you created a new plane by checking the neightbouring vertices if so adds a new face rebuilds the brush and check if its valid

but what would you do if you have more than one vertex selected?
check if they are on the same plane otherwise transform each vertex on its own and rebuild the brush for each selected vertex


if so you had to store the vertices in the brush
and each face had to store a list of vertex indices
and a list of uv coordinates for the face


i think i will implement terrain meshes first is easier and you see some results ^^