Is it possible writing a tool to convert the Duke Nukem MAP level files into BSPs? I know that some levels have sectors overlapping sectors, hidden sectors intersecting sectors, etc. but you could work around it. As with the dynamic Duke Nukem levels (eg, sectors changing height, etc.) you can still convert these to normal BSP levels with moving lifts, etc.
Am just thinking it would be great to see Duke Nukem 3D in fully true 3D (opposed to the skewy ness you get when you look up/down in original Duke Nukem 3D).
This idea has already been successfully done in Doomsday/JDoom (http://www.doomsdayhq.com/) using glBSP and think Duke Nukem 3D could be done the same way.
Minion at
Am just thinking it would be great to see Duke Nukem 3D in fully true 3D (opposed to the skewy ness you get when you look up/down in original Duke Nukem 3D).
jfDuke is fully 3D with correct mouselook. Change the renderer to polymost.
jDoom looks neat though :o
noctrun at
Re: IDEA: converting D3D levels into true BSP trees...
I am affraid you don't know what glbsp's opengl friendly notes are needed for in doom engines:
Why GL-Nodes are needed from http://glbsp.sourceforge.net/specs.php
OpenGL rendering requires all surfaces to be polygons. For DOOM and its derivatives (like Heretic & Hexen) this means the walls, floors and ceilings need to be made into polygons.
Walls are no trouble, but the floors and ceilings in DOOM levels are only roughly defined (as the gaps between walls). Thus an OpenGL port of DOOM (hereafter called the "engine") requires the floors and ceilings to be "polygonised", to make sure they are convex, and to find the precise edges.
An obvious way of polygonising a DOOM level is to use the BSP tree contained in the SEGS, SSECTORS and NODES lumps. The BSP tree already provides convex subsectors, so the main work is to determine all of the edges of these subsectors (since the BSP info in DOOM levels only includes edges which lie along linedefs).
The main problem with this approach is that some node builders create BSP trees where certain subsectors are not purely convex (especially when the segs are included as boundaries).
The other concern with polygonisation is that the process can be very time consuming. It should only be needed to be done once, and preferably by the author of the WAD file (and not the user).
it's a mystery to me why you believe that a change in/addition to the map format is suppost to (magically) fix the renderer issue in polymost with looking up and down
kevingpo at
IDEA: converting D3D levels into true BSP trees...
The mouse doesn't look 100% up or down. But it does look good for a 3Dness feel.
The conversion to BSP was an idea so that we can play the levels in engines like Half-Life or Quake3.
Also, erm, the TAB map-overview doesn't work... yet?
maniac1701 at
because of the way duke3d is designed you can't posibly convert it into bsps. the problem is moving sectors. in a bsp nothing is permited to move (this allows the polygons to be broken down untill they can be sorted according to the current depth but if something moves the bsp tree becomes useless) and because nothing can move you would have a real problem with levels that have subways and trains etc.... well what about quake (1, 2 ,3, doom iii) well im fairly certain that its a hybrid engine. it draws the static level with bsp's then it goes back and draws the doors, players, weapons, etc... (yes in quake a weapon and a door are treated the same way graphically) using z buffering or posibly some other algorythem but none of the final objects can be drawn using bsp trees. in fact i used to know a command in quake 1 that would draw bsp's only (no doors weapons players or anything else besides the basic level)
Minion at
kevingpo said
The mouse doesn't look 100% up or down. But it does look good for a 3Dness feel.
The conversion to BSP was an idea so that we can play the levels in engines like Half-Life or Quake3.
Also, erm, the TAB map-overview doesn't work... yet?
The D3D map format is too dynamic for full BSP support.
Besides you'd be better off just rebuilding the maps for a BSP engine. Half the fun in updating a game to run on a new platform is making it look better, not just doing a straight conversion.
Edit: Additionally the fact that you can't look straight up/down is a camera restriction not that of the map format.
TylerDurden at
Well, I already did the conversion to BSP with a tool that made the Duke3d maps readable for the program "WorldCraft" (for Halflife).
In a second step I extracted & converted all textures from Duke3d as described in the converters manual and created a Duke3d.wad-file out of them.
But the problem within Worldcraft itself was that the Duke Maps are a lot too big(!) for Wordcraft/Halflife... so my next step was to resize all objects in the map with the option Worldcraft already has built-in (a long time ago, so I can't remember much of that project). Finally when I compiled single parts of the whole converted map, they actually worked within the Half-life game :wink:. => I tried to fix some conversion and texture errors and further I began to script the objects again because all scripts had NOT been converted :(. [...]
Overall, I think it is a nice idea to get Duke maps running under HL, but the HL engine basically isn't made for it... it has too many features needing to many splitted mapfiles and long compile periods - please forget about it - would take to many time to establish even one level as you knew it from duke! (I never got my first and last map "Launch Facility fully finished)
kevingpo at
TylerDurden said
Well, I already did the conversion to BSP with a tool that made the Duke3d maps readable for the program "WorldCraft" (for Halflife).
In a second step I extracted & converted all textures from Duke3d as described in the converters manual and created a Duke3d.wad-file out of them.
<snip>
Wow, that's amazing! Do you still have your project files (scripts, convertors, etc)? I still think you could create the static BSP tree level with sectors that are not dynamic. And for sectors that raise/lower during gameplay, create then out of lifts or something. The only problem I see is slanting/slope-changing them.
kevingpo at
http://www.planetduke.com/mapconverter/
I found this when browsing on PlantDuke's website. I wonder if it can do it in reverse. Converting BSP into MAP.
Minion at
kevingpo said
http://www.planetduke.com/mapconverter/
I found this when browsing on PlantDuke's website. I wonder if it can do it in reverse. Converting BSP into MAP.
I don't see how that would be even remotely possible. Map to BSP is one thing because the static geometry in maps is dramaticly simpler than that of a BSP. Trying to take complex geometry and simplify it into a .map is entirely different.
kevingpo at
Minion said
kevingpo said
http://www.planetduke.com/mapconverter/
I found this when browsing on PlantDuke's website. I wonder if it can do it in reverse. Converting BSP into MAP.
I don't see how that would be even remotely possible. Map to BSP is one thing because the static geometry in maps is dramaticly simpler than that of a BSP. Trying to take complex geometry and simplify it into a .map is entirely different.
True. I was thinking of taking all the geometry horizontally (ignoring slopes, heights or anything in the z (vertical) axis) for the moment/time being. Then draw out the horizontal geometry using the connected x,y lines/points. I just wanted to make a general outline/guidelines that you can then further work on.
TylerDurden at
So,
some days ago I found my old files... I'll try to upload them when I find free FTP space and time for it :wink:. Has anyone of you a little place on a server with "free" upload rights? I think I would need about 50 megs???
Greetz,
Tyler
P.S.: The Mapconv you found was the one I used... it is going into the right direction.
In a second step I reduced the "world-size" (in half-life) by 1/2 if I remember correctly that all sectors from duke fit into one BSP-level.
TylerDurden at
Ahh it's terrible but I currently have no time at all for anything *arrrgh* ;-).
So here are some files I found from that project I did some years ago... if you are missing anything feel free to post, could be I forgot a file or hint :? ?!
The Map Converter (with tutorial, would be nice if the author would still enhance its functionalities *g*)
Link removed
A (small) Part of my converted "Launch Facility" from Episode one I still had on my hd Link removed
My custom "Duke3D.wad"-file which I built with... I think... it was "Wally" :-D (I had to split this into ace-multi-volume so my hoster does not delete it, hope all files are still there!)
Links removed
Greetz,
Tyler
Edit by TX: it's inappropriate to post .wad files containing all of the Duke art.
Makoto at
...or maybe...
maybe it'd be a good idea to implement bsp support in JFD itself so one can make fully 3d custom maps for DN3D that will still look "duke-ish".
The Commander at
IDEA: converting D3D levels into true BSP trees...
Maybe you should just go get halflife and convert that to duke nukem?
Can you see the point im getting at here? You cant put bsp in to duke nukem because then it wont be using the build engine then it just wouldnt be Duke Nukem any more and no fun...
Makoto at
the gameplay and the game appearance (textures/entities etc) would pretty much be the same... and if the engine behind it all worked fine, i don't know what the problem would be. some doom ports use quake-like rendering too, so technically "it's not doom anymore". we could discuss implementing md2 models into DN3D the same way, they don't really belong here and they do look different... but if it suits some people, why not?
besides, coming up with that idea i didn't consider it any high priority thing i'd desperately look forward to see... and perhaps it requires too much work, too.