Questions about 3DGE technical abilities

[Marscaleb]

Long story short, I was thinking about the technical capabilities of 3DGE, and was wondering about some things that might be interesting to see in the engine.

First of all, I notice that on the list of planned features, there is "Quake 3 BSP support." This sounds very interesting, but how is it intended to work? Would 3DGE be just running either a Doom map or a Quake map? Or would 3DGE be running a Doom map with Quake 3 BSP inside it? (So like if I wanted to make a structure, instead of building it out of sectors, I could build it in a quake editor and them just import a whole structure into my map.)
I'm also curious how likely this is to happen, and what sort of timeframe it would be before we see it. Sure, there are other things taking priority like the inventory system. But I am new here so I don't know if this is some "pie in the sky" sort of plan, or if the engine already has some of the groundwork laid.

My second technical question is about overlapping sectors. So I have seen that 3DGE does allow the "3D floors" trick of having sectors that become room-over-room, but while functional, some designs are a bit tricky to pull off. What might be simpler is an overlapping sector, so I can build a room over another room, and freely build the geometry without concern for setting up the geometry in the room below it. Now granted, we're not talking about emulating how Build can use overlapping sectors to warp reality; I'm just talking about overlapping sectors to create 3D geometry. After all, this is technically a 3D engine, rendering 3D geometry. I am thinking of just using the sectors as snippets of 3D geometry.

I just made a quick test in Doom Builder, and it will let me actually create what I am thinking about, and render it correctly within the editor:

...But in 3DGE, not so much.

I was also blocked by the walls.
I'm curious if there are plans to improve this in the future. Especially if the engine is going to support Quake 3 BSP, it might need the capacity to render this properly. But then again, is this even possible? Is it within the engine's capacity without a major overhaul?

And finally, one other stray thought.
I know this was not possible in the original Doom engine, but I don't know the inner-workings of 3DGE, so...
Is it possible for 3DGE to move the vertices of a sector in-game? To re-size and re-shape sectors? I mean, once again, this is now a 3D engine rendering geometry with OpenGL. So the renderer wouldn't care what is stationary and what is not. But has 3DGE drifted far enough away form the original Doom that this could be possible?
Granted, anything you want to do still needs to be programmed in, so as to instruct the engine HOW to re-shape the sectors. But is this something that is technically possible? Or rather, technically possible without completely overhauling the engine?

I was just curious; just thinking about ways I might extend the capabilities of what I build.

[Corbachu]

Q3BSP is still on the table, but me and the rendering guys are still trying to get OpenGL2 mode working, and concentrating on other more important stuff (speeding up the BSP tree calculations, etc). It will work similar to how you describe it, as the "DOOM" map will only need to be a solid box -- as long as the Q3 BSP is in the middle of it, it will work. There have also been light talks about supporting the entire map format on its own, but when we get there I will let you know =)

As far as resizing and reshaping sectors, there is no current way to do this easily, but you can get RSCRIPT (RTS) to do pretty much anything like that.

Also, the MOVE_SECTOR command in RTS is pretty robust, as well.

The RTS editing guide is down right now, but once it gets back up I can link you to it.

As far as other stuff, I am still working on Polyobjects, which should liven up RTS a bit

EDIT: Does that trick you linked to in Doom Builder work in other OpenGL engines?

[Marscaleb]

As far as resizing and reshaping sectors, there is no current way to do this easily, but you can get RSCRIPT (RTS) to do pretty much anything like that.

Also, the MOVE_SECTOR command in RTS is pretty robust, as well.

That actually sounds more promising than I had thought.
Honestly I am not expecting any of this to work at this time, I'm just kinda thinking ahead. If/when I get the chance to go whole hog with 3DGE on my next project, I want to know what sort of things are on the table. A lot of this came from the thought of "Would it be easier to modify Shadow Warrior to add new weapons as easily as I can in 3DGE, or would it be easier to modify 3DGE to do the few sector tricks I want from Build?"

It sounds like you are saying I could actually change level geometry; actually move and reshape sectors in-game, which means that one could ideally create the sector deformation effects that Build can do. Assuming I can put in the time to code the logic of HOW to deform the sector, but the point is that the fundamental changes CAN be made.

I thought the MOVE_SECTOR stuff was just directly adjusting a sector's height and the like.

As far as other stuff, I am still working on Polyobjects, which should liven up RTS a bit

Curiosity piqued. What are they?

EDIT: Does that trick you linked to in Doom Builder work in other OpenGL engines?

Lemmie check...
Nope. They have the same problem but produce a hall-of-mirrors effect.
It IS after all something that is completely contrary to the nature of the original Doom. But if this engine is aiming to be able to handle Quake 3 maps, well then, maybe it might handle something like that as well.

[Corbachu]

PolyObjects are from Hexen, which enabled limited real-time movable geometry in a much simpler fashion (rotating doors, sectors, etc), though with RTS you can do this already with written scripts (and you really aren't limited, either), without limitations that Hexen imposed.

You can also do wild things with line and sector types - create, edit, and have them reference RTS scripts as well -- so say you want a door to open diagonally in one place, and then the next is locked - get the key, that one opens differently, etc etc - get to the last one, and its sealed off - pull out a rocket launcher, blow it all to hell, which might blow holes into other geometry nearby, and keep going.

There really is a lot you can do with it - I've created crazy things that start with DDF, push through RTS which checks COAL, and pushes back -- lots of neat tricks to pull off. ^_^

[Marscaleb]

PolyObjects are from Hexen, which enabled limited real-time movable geometry in a much simpler fashion (rotating doors, sectors, etc),

Ohhh yeah.
Yeah I have read about those; it's just that with a name like "PolyObject" I'm expecting something cooler.

Something I have been thinking would be sweet to implement would be a 3D animated door. I'm sure the engine is technically capable of handling it; just a matter of actually writing code.
Conceptually, you put in an md2 or md3 file and position it in a doorway. When it is triggered, it plays an animation for the door opening, and changes some flags for its solidity. Exactly how it would block players and things would depend on how collision is set up within the engine. When you get Quake BSP working you'll probably need to revise a lot of that anyway. If it becomes robust enough the door could potentially even operate its collision per-poly. Otherwise it could just use a simple box collider that gets activated and deactivated (or possibly resized, in case you have a sliding door.) Or at the very least, the door could be connected to a linedef and it would make a line become passable or not. The ideal fashion would be to allow all of these methods, so you can also use the effect that works best for the situation.

But THAT is the sort of thing that comes to my mind when I hear "PolyObject." Something way more modern and dynamic than Hexen's sliding doors.

[Corbachu]

We were planning on finer hit detection for 3D models sometime in the future for stuff like this, so hopefully we can get it worked on shortly

[Marscaleb]

Oh yeah, I keep forgetting about it, but something else I think might be useful is allowing the engine to not care if a graphic it is applying to a surface not care if it is a flat or a texture or perhaps even just a patch.

It might be something that would also require some sort of update to Doom Builder, but it is the sort of thing that seems to me to be the way things ought to go. I mean, using a GL render outright nullifies the benefit of storing flats and textures in different formats. So it just seems arbitrary to have to separate the textures I use into two groups and duplicate any texture that appears in both.

But for all I know this is already an option but I just need to get a fixed version of 3DGE's Doom Builder.

[Corbachu]

You can do this already - I don't remember how to do it in the editor, but essentially the engine should allow you to map anything to any surface as long as it is named in Images.ddf and referenced correctly. I believe it also works with regular Doom-type images as well, even if the level editor doesnt pick up on it, the engine will map it regardless.

You can also define animated graphics, textures, and surfaces via DDFANIM.