News | Forum | People | FAQ | Links | Search | Register | Log in
OBJ-2-MAP V1.1
So I added a few new features to my OBJ-2-MAP utility and put together a small web page explaining how to use it.

This is a utility that can take OBJ files exported from any modeling app and convert the geometry inside into Quake brushes.

Have at it! I think everything will work.

[edit: updated url]
First | Previous | Next | Last
any other games you guys deem worthy? 
Meaning n64 quake's maps were simplified versions of the actual stock maps we've seen already? 
that's right. Quake 64 were simplified versions of the id maps. Doom 64 and Quake 2 were completely new. 
doesn't this "export geometry to VRML" work with visible geometry only? 
so in order to export large regions you need to do multiple parses. 
Cut out areas in each map. I think the DM ones survived, apart from DM3, which I vaguely remember was cut completely. 
Yes, the N64 maps were lower poly versions of the stock id maps, but even so that conversion pipeline you posted would be a horrible way to do it considering they were most likely in the same or similar quake .bsp format, so I assume the triangulation of the geometry would be a horrific mess like in a typical quake bsp. 
Did few more tests with geometry triangulated before OBJ export:
Still doesn't show in editor.
Tried to explode mesh to separate objects by planar surfaces and export as single OBJ. (Dragged apart just to demonstrate separation, actual export had it all composed to form original shape from first image.)
In editor each plane was enormous.
I suspect brush[es] is too big to fit editor's working area every time I'm seeing nothing on map load, but can't confirm.
Divided in 3 objects.
Those 2 broken cubes in the middle is one obect.
That worked a bit better - holes automatically capped, but middle part is missing.
Same as before, but each broken cube is separate object now.
Results in this:
Cube parts go to "infinity". At least far beyond the end of editor grid.

OBJ files: 
I doubt they're in bsp format. Even if they are, the rom dump process probably doesn't retain any semblance of a file format. It's probably the simplest way without actually reverse engineering the rom programming.

you could *try* and hope for some success with watching memory for bsp headers, it's just so unlikely though. In all likelihood the programmers stripped all superfluous data from the game to save space. 
True. Console games are generally munged pretty harshly to get into memory. Headers and such are right the fuck out... 

Try this one again:

But cap all the geometry in Blender so there aren't any holes. OBJ2MAP doesn't add capping geometry or do anything other than convert triangles to planes. You need to feed it valid Quake geometry. 
In other words, the cubes extending to infinity is totally expected ... there aren't any side planes to clip it against. 
To see it in action, feed it a cube and look at the results. Then remove one of the cube faces, run it through again, and see what happens.

That should solidify what's going on in your mind. :) 
I Dont Think They're BSP 
I believe they're their own proprietary format. Oddly when Quake was ported to Saturn, for example, it used the same engine as Saturn Duke and Saturn Exhumed... 
Cool article on reverse-engineering saturn quake: 
What confused me is that in some specific conditions it acts as if it had that functionality.
Specifically this
producing that

Capping aside, breaking geometry to group of convex shapes by hand, opens gate for human error. Not to mention might be extremely time consuming.
From the top of my head - I can't imagine a good way to break inverted hemisphere to chunks of valid geometry. 
It's just the way of it. OBJ2MAP isn't doing anything hardcore magical ... it's just converting one file format into another. So there is some burden on the modeler to make sure the geo is Quake friendly to begin with. 
until you add it you're going to be fielding these concerns until the end of time :)

see: everyone asking sleepwalkr why their map leaks or whatever "in trenchbroom" 
re: "this producing that", the black plane on the piece on the right side extends to seal off the solid.

Capping aside, breaking geometry to group of convex shapes by hand, opens gate for human error. Not to mention might be extremely time consuming.
Yeah, one possible way is build a bsp tree out of the concave geometry, which makes slices that gives you convex pieces. But the downside is it will probably make ugly slices that a human wouldn't choose. 
From What I Saw So Far 
in convex shapes with gaps, every open edge will be extended until it intersects with something.
In case of cube with one side removed, all faces a parallel, thus continue forever.

But say we remove top face of the cube and then scale up bottom face. This will produce a pyramid by extending faces until intersection point.
For me this is magic! That kinda blows my mind and imagination goes wild.

For example.
Maybe I'm completely wrong here and think that easy things are hard and vice versa, but I'd guess that tool is already creating geometry that wasn't there in OBJ file and if it can detect intersection the same way it can detect the ... uhm, lack of it, to create caps using last known finite vertices.

Alas my knowledge of magic is insufficient to imagine "perfect solution" for solving problem with concave geometry. 8/ 
"but I'd guess that tool is already creating geometry that wasn't there in OBJ file"

Technically, no. It's creating plane definitions in the resulting MAP file. The infinite geo and such that you're seeing is being created by the map editor you're loading that MAP file into ... 
not all faces are parallel, but their extrusion direction. 
Well now you destroyed all the magic, mate. 
Sorry. Just trying to interject some reality. :P

felt like reposting this again.

You can make valid cubes by just having 6 triangles. You need those cutting planes or indeed it goes on forever. Once you get the logic its easy to build brushes. 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.