Sotware-rendered 3D preview in a map editor?

[scifista42]

What does prevent Doom map editors from featuring a 3D preview mode that renders the map exactly like Doom's software renderer does, using the map's nodes and everything? It would come in handy if the mapper wanted to quickly check out exact appearance of light diminishing, animations, visibility of map objects, and even test collisions. There would be modified controls of course, flight/non-flight mode, collision/non-collision mode, etc. I would live with not being able to look perfectly up or down.

[Superluigieth1]

People would just reply with - DUH U C DAT DERE IZ TEZTIN V3R5I0N DUUUUH , but I would just say - I agree, but it already has happened *cough* *cough* doom builder's extra tools *cough* *cough*

[scifista42]

I know about the standard OpenGL-based 3D preview in DB2/GZDB, I use it a lot. But I was talking about a software-rendered one, I even mentioned the differences that would a software-rendered preview bring. If that's what you mean as well, and if there's an actual software-rendered preview tool, would you give me a proper link, please?

[Gez]

The idea isn't without merit, but there are more than a few drawbacks as well

1. It makes node building necessary before entering 3D mode. Nowadays it's a very fast process, even for huge maps, but it's still quite a bit of overhead to deal with.
2. View pitch cannot be changed, best you can do is some Y-shearing. This can make it impossible to perform actions in 3D mode on floors, ceilings, and upper and lower sidedefs if you can't position the viewpoint in such a way that they're selected.
3. Because of 2, there would still be a need for a "normal" 3D mode, meaning that the software mode would be redundant.



Also DB2/GZDB's preview mode is not OpenGL based, it's Direct3D based, because lol if you think Microsoft's Microsoft .NET would use an OpenGL backend. You want an OpenGL preview, try SLADE's instead.

[scifista42]

Gez said:

1. It makes node building necessary before entering 3D mode. Nowadays it's a very fast process, even for huge maps, but it's still quite a bit of overhead to deal with.
2. View pitch cannot be changed, best you can do is some Y-shearing. This can make it impossible to perform actions in 3D mode on floors, ceilings, and upper and lower sidedefs if you can't position the viewpoint in such a way that they're selected.
3. Because of 2, there would still be a need for a "normal" 3D mode, meaning that the software mode would be redundant.

I was aware of all these drawbacks (I disagree with your point 3 though), and I know that none of them is a deal-breaker, neither for developers, nor for mappers. That said, I can't imagine how much effort would be needed to make such a software preview plugin. I was merely curious, and also wanted to announce that I'd appreciate the feature if it existed.

[Da Werecat]

Marathon mappers worked in harsher conditions since the very beginning. Visual mode in the official editor was based on the game code - you walked around, opened doors, and textured everything instead of shooting stuff. Physics worked, but entities didn't spawn.

Even now the most popular toolchain includes a special plugin for the one and only Marathon source port that behaves more or less like that visual mode.

On the other hand, Marathon maps don't require compilation, AFAIK.

[Nevander]

Da Werecat said:

Marathon mappers worked in harsher conditions since the very beginning. Visual mode in the official editor was based on the game code - you walked around, opened doors, and textured everything instead of shooting stuff. Physics worked, but entities didn't spawn.

Even now the most popular toolchain includes a special plugin for the one and only Marathon source port that behaves more or less like that visual mode.

On the other hand, Marathon maps don't require compilation, AFAIK.

You're talking about Aleph One aren't you? I enjoy Marathon, but I just wish the darned engine wasn't hard-coded to a 30 FPS lock.

[Enjay]

scifista42 said:

(I disagree with your point 3 though)

Dunno, if you can't look at the floor/ceiling, it makes it harder to edit them.

Da Werecat said:

Marathon mappers worked in harsher conditions since the very beginning. Visual mode in the official editor was based on the game code - you walked around, opened doors, and textured everything instead of shooting stuff. Physics worked, but entities didn't spawn.

Doom mappers worked in harsher conditions too. Remember that a visual mode in Doom editors is a relatively recent thing. The Build engine had one long, long before Doom.

[Da Werecat]

Nevander said:

You're talking about Aleph One aren't you?

Yes.

Enjay said:

Doom mappers worked in harsher conditions too.

I meant harsher than simply having Y-shearing in visual mode.

[TimeOfDeath]

Gez said:

1. It makes node building necessary before entering 3D mode. Nowadays it's a very fast process, even for huge maps, but it's still quite a bit of overhead to deal with.

Is that a db2 thing? On my comp, db1 builds nodes before going into 3d mode.

[Enjay]

Da Werecat said:

I meant harsher than simply having Y-shearing in visual mode.

Well, I meant that having no visual mode whatsoever was hasher than that. ;)

[boris]

TimeOfDeath said:

Is that a db2 thing? On my comp, db1 builds nodes before going into 3d mode.

DB2 doesn't need nodes for 3D mode anymore.

[MaxED]

scifista42 said:

What does prevent Doom map editors from featuring a 3D preview mode that renders the map exactly like Doom's software renderer does, using the map's nodes and everything?

Nothing.

[andrewj]

Eureka's 3D mode is a software renderer, but uses quite different methods than the DOOM renderer and has a few differences (e.g. sky is not always the same).