level editor design

It should provide the user with instant visual feedback. For example in the Quake and Half-Life Editors you can't see the light in the editor which is a major drawback in my opinion.

Quote:

Original post by noVum It should provide the user with instant visual feedback. For example in the Quake and Half-Life Editors you can't see the light in the editor which is a major drawback in my opinion.

I'd have to disagree and say performance is more important during level editing. When it comes time to preview, you can have lighting effects. However, UnrealEd already does this.

On the UI side try to make everything customisable i.e. have everything dockable/hidable etc and be able to alter what's on the various toolbars. Having a fixed UI that allows no customisation can be very annoying if you don't like the way it's layed out.

Yes, all the components are currently dockable (in the design) using a dockable framework I have already written. This includes the viewports, all tools, resource browsers, etc. They can be torn out into their own window, and docked anywhere. As for the lighting, it will probably mimic UnrealEd for the most part. The engine currently does not support all dynamic lighting (i.e. doom3).

Thanks for the replies thus far!

Quote:

I'd have to disagree and say performance is more important during level editing. When it comes time to preview, you can have lighting effects. However, UnrealEd already does this.

Uhm. UnrealEd does have an instant visual feedback when you add a light. It's not accurate, but better than nothing.

But that was not my point. In Quake/Half-Life you have to start the game, and do a very long level rebuild before you can see the results.

thats because you need to compile your maps to create BSP Trees out of convex geometry + generating PVS and lightmaps

in modern engine that don t use PVS and lightmaps anymore all you need is a proper map formal to decrease map loading times

the engine will set up everything else on its own

e.g.:
- static shadow maps
- octree/quadtree ... what ever you use
- no pvs needed you can use frustrum culling and apply occlusion culling on your frustrum culled nodes

just sort the culled nodes by distance from the camera

a) render the first node
while(there arenodes){
b) enable occlussion query /disable depth buffer writing
c) render the BBox of the next node
d) get number of pixels compared to the depth buffer
e) if enough pixel were drawn draw enable depth buffer writing render the node into the depth buffer
f) mark node as visible

go on for each node *end while()*

ok back to topic

to add to the points already mentioned
create a base object class and derive all the subclasses from this one

the reason why is because you don t want to rewrite the same code all over again

so a proper class hierarchy is a must !
implement a function called CLASS_ID() as you might know from 3dsmax node base editing system

this function returns the class id of your object so you can do proper castings here and there

that makes it a lot easier to handle your objects within the editing process

follow the concept the OOP

each class shall contain the routines to manipulate itself instead of manipulation it by a foreign function/object

that simplyfies the developing process

you simply write more code to write less code in the end ^^

if you would like to talk about how to develop your editor i am working on my own one at the moment
i would be interested in talking to you


cya

[Edited by - Basiror on September 10, 2008 4:04:33 AM]

Yeah, the object hierarchy has already been designed. It also supports a plugin style mechanism for extending the default entity types supported by the engine. This way, you can code your entities in a dll/.so file, where the code has hooks to export the classes to the level editor. Then use them in a plugin style fashion. I envision people sharing libaries of entities amoungst each other as well. A flexible and extensible entity construction system is a major requirement in the requirements doc for the level editor. As for ICQ, I do not get on instant messenging programs much so PM me and I'll send you my work email address.

Quote:

thats because you need to compile your maps to create BSP Trees out of convex geometry + generating PVS and lightmaps

I know. But there is still no reason why you can't display the calculated lightmap in the editor.

Unreal does it. The Quake editor looks like a big hack without workflow in mind.

you export classes from a dll?

isn t that tricky like hell?

http://www.codeguru.com/dll/expclass.shtml

^^ ugly code


i did it the following way

i have build a class hierarchy
put everything in .h files as long as i am working on it

once it is finished i ll use the .h to compile a library and link this into the executeable

that way i can reuse my geometry hierarchy for terrain deformations inside my engine or do other fancy things with it

the problem comes when storing the objects in a file format suitable for rendering

i want to implement a physique engine into my engine so i ll have to see how to pass collision meshes to it

+ i want to do terrain deformations and real wall destruction

all this needs a clever system to establish it with as less CPU cost as possible