For example how can you write a tool to generate light maps if your renderer requires a light map?

You would have a blank screen to work with until the light map is generated.

Why would your engine try to use lightmaps that don’t exist? If lightmaps available, use them, if not, render the base colors for objects. I don’t see the problem here.

It's nice to be able to use the same renderer, but you have to have another renderer to use when you are working.

Correction: It’s nice to have a modified version of the same renderer. IE if the library is built with the LSE_TOOLS macro defined certain features are added/modified.
You don’t have to waste time rewriting a renderer and the shipped games don’t have any extra cruft that might degrade their performance.

Load in a million point terrain mesh and try to display it with your game renderer, chunk your machine, get less than 1fps and try to work with it.

Why would the editor be able to display any of the same graphics faster than the game engine?

Display it using a simple point display, let the editor convert it into chunks and build display lists etc. Then render it with the final renderer.

Point displays would simply be the same renderer with an LSE_TOOLS feature for displaying terrain as points.
In fact you don’t even need it to be just a feature of LSE_TOOLS builds; just have the editor set the terrain’s rendering states to draw points.

The editor has to be able to display whatever elements you need in the final game and generate the elements the final renderer needs to be able to operate quickly, therefore it HAS TO have it's own renderer.

Never use blanket statements such “HAS TO”.
I’ve just provided a very good alternative to the tools having their own renderers.

Also why spend time writing code for all the gui widgets you would need for an editor, and then ship them in the game?

Who said anything about making GUI widgets for the editor? The engine renders into a specific window inside QT or some other window-based application that forms your editor.

I drop an OpenGL or XNA window into a windows form application and then use all the toys windows gives me for free. Saving me massive amounts of time writing folder browser dialogs, file dialogs, etc.etc.etc.

This was implicit from the beginning and everyone does this. The fact that you even mentioned it indicates you don’t really understand what is meant by “use the renderer that already exists in your engine”.
Apparently you think that just because the game engine has a built-in GUI that you are for some reason obligated to use that in your tools.
No, you use the engine renderer to render all kinds of things, from the 3D view to the texture previewer to the shader previewer with all the 3D balls…
Not the GUI. That comes from the operating system.

The editor is not a product you are going to sell, so why spend the resources on it if you don't need to.

Logical error #1: Why would I sell my engine but not the editor?
Logical error #2: I’m not selling the engine either. Guess I shouldn’t put time into that either.
Rebuttal: But you are selling the game which depends on the quality of the engine.
Logical error #3: It also depends on the quality of the tools. In fact tools are really what makes or breaks a studio.

so why spend the resources on it if you don't need to.

Unneeded resources, like making a second renderer?


You’ve not made a case in favor of making a second renderer, most likely because you seem not understand what it means to use the engine renderer.
Drawing terrain as points is a simple matter of changing the render state for terrain (and is unrelated to any shipped-product run-time costs because you simply don’t use that render state in the shipped product) and other features that would cause shipped-product run-time overhead (such as fallback code when materials, shaders, or lightmaps are missing) is a simple matter of some kind of tool-only macro you add to the same renderer.

Just because your engine has a GUI doesn’t mean you use it; you use the operating system’s GUI—of coooourse.
But guess what? You will need it when you make another tool for GUI-editing. Do you propose yet a third custom renderer? How many times do you propose we rewrite renderers?

And finally, why spend resources on a separate renderer if you don’t need to?


L. Spiro

It's good when your game needs in-game gui, for example, unreal engine 4 editor use the in-game GUI system.

Most (all?) games need an in-game GUI.
How extensive it is depends on the amount of money the company has.

For normal people, no widgets are added to the engine just for tool-side purposes. The operating system’s GUI is used.


L. Spiro