Q3Radiant Map Exporter by Milkshape 3D [DLPUF]

[a13n]

Today I happened to re-evaluate Milkshape 3D and re-tried q3radiant map exporter.

1stly I made a simple cylinder in gmax then deleted the meshes except the top one.
Then I exported this circular flat plane as a md3.

Next I imported it in milkshape to convert to *.map file.

I found this procedure really convenient to generate shape or prefab for q3radiant.

What do you think about this method?

ref pic

[Kat]

erm... so the benefit of doing this is what exactly? Why not just leave it as an MD3? (aside from the obvious comment about using ASE models) Load up gMaxTempest and use that it you want a map file.

It kind of defeats the whole purpose of using a modelling package if you then convert it back to basic brushwork, esp considering models tend to be more complex objects (which is why you used it in the 1st place) which as brushwork is going to give the compiler a few headaches.

[a13n]

Are you kidding?
There is an apparent benefit, the time saver.
If you try to sculpt the equivalent brush in radiant, it will take a lot more time and it might not be precious in the end.
By using modeling tools you can have total control how you sculpt the shape in advance and it's done immediately.

My next map will make full use of this procedure. :icon26:

[obsidian]

What Kat means is, why not just export it from Gmax as an ASE/MD3 and import directly into Radiant. Skips milkshape importing and exporting entirely.

Besides, brush vertexes sitting off grid have been very well known to cause all sorts of problems. Don't say I didn't warn you.

[a13n]

The Reason:
1. to cull effectively
2. to support bots
3. on top of that, to have fun

I'll see if I could survive supposed all sorts of problems.
If I could, I'll post a beta. :icon26:

BTW, the most important thing for this procedure is to keep things "plained".

[Kat]

Are you kidding?
There is an apparent benefit, the time saver.

Time saving?!

So....

building the thing in gmax and making sure you're snapped to the grid and you're using the right sizing; exporting to MD3 and making sure you've got the texture paths right and all the fiddling that sometimes requires; importing the MD3 into MS and then checking the UVWmapping and shader paths have imported correctly; then exporting the results back out to the .map format and opening that into Radiant *as brushwork* all to then recheck texture paths UVWmaps and alignment...

Is faster than,

.... building and texturing the thing in Radiant in the first place.

Yes I can quite see how the former method would be faster

If you try to sculpt the equivalent brush in radiant, it will take a lot more time and it might not be precious in the end.

If 'scultping' is a concern you shouldn't be converting it *back* to brushwork becasue as you know, brushes are not that tollerant of fine details; it's why models are used for more complex & detailed shapes

By using modeling tools you can have total control how you sculpt the shape in advance and it's done immediately.

erm.... (see above)

My next map will make full use of this procedure. :icon26:

ok

As it looks like this method is building content without regard to Radiant and grid snapping I'll requote obsidian here

Besides, brush vertexes sitting off grid have been very well known to cause all sorts of problems. Don't say I didn't warn you.

[Kat]

The Reason:
1. to cull effectively
2. to support bots
3. on top of that, to have fun

I'll see if I could survive supposed all sorts of problems.
If I could, I'll post a beta. :icon26:

BTW, the most important thing for this procedure is to keep things "plained".

1) Correct construction (as in 'tidy' brushwork) does that, not necessarily the method.
2) Bot support is down to correct or 'mindfull' construction (being aware of how bots behave).
3) You're better off promoting this as a way to have 'fun' than a legitimate production methodology; introducing the use of two additional software packages to produce *brushwork* is not efficient or time saving in the least; you might be able to do this quickly becasue you already know how to use those applications, for other people it won't be.

If you don't get any problems, you'll be lucky.

oh and regarding the 'plained' comment, the complexity of the map is going to dictate that, mind you, it's slightly moot if you're using the boxhull method anyway (which you should be doing where ever possible).

[dnky]

The only reason I could possibly think of for converting a model into brushes is the following:
If for some reason I made a BIG chnage to the detailed mesh that will be my playable area, and it no longer fitted inside my caulk hull. Perhaps I might then remake the caulk hull in the model application, rather than try to fiddle about in Radiant. On a few occasions where I have wanted to increase the dimensions of a mesh, this could have been useful.
I can see no point at all in converting a detailed mesh into brushes. If I really want bots to play a map made more or less entirely from models, then my best approach is to clip it, not turn it back into brushes, which if they were complex enough to require modelling in the first place are going to confuse bots anyway.

[4days]

will have to have a look at how easy/reliable the milkshape part is - one of the many things that keeps me from mapping is a lack of patience with copying and pasting once i know what i want to do (make a particular shape or structure, etc.). don't remember milkshape being very difficult to use.

if you could make something up in milkshape and then dump it into quark/radiant as brushwork for a bit of tidying up, that could be really handy.

never used gmax, what's that stage for?

[Kat]

Maybe I'm missing something here but I still don't understand why you'd want to convert a *model* (object made in a 3D app) back into brushwork, it kind of defeats the whole point of using a 3D app; if you're doing something that requires the use of a modelling app it's usually becasue you can't (easily) create it in Radiant, in which case you'd leave it as a model.

[dnky]

I think this may be an instance of modelism that we've talked about, Kat. Maps made out of model are somehow inferior to those made from brushes. I'm going to start an equal rights for models pressure group.

[seremtan]

i'm amazed there aren't more maps made 90% of models with caulk thrown in for VIS purposes. it's not like r_speeds are that big a deal any more when you consider that GF2 was the shit when Q3 came out now a 7600 is considered middle of the road

[obsidian]

Models and brushes each have their own advantages and disadvantages and they are not interchangeable with each other. Sure, you can use a screwdriver as a can opener, but a can opener will do a better job. You can be creative and do the same vice versa, but wouldn't it be easier to just use the right tool for the right job?

Brushes are great for rapid prototyping, which is important for game design since scale and game play dictates the need for a lot of quick changes to the structure of the map. Texturing brushes and patches are also a snap.

Models on the other hand are really fussy when it comes to editing them. You have to apply UVW coordinates for textures and make sure seams are properly tiled. What they are good for is high frequency details and complex shapes that simply aren't possible with brushes.

If you look at games that have been built predominantly in modeling apps (IIRC, Halo 1) you'll notice the amount of repetition. All the hallways look the same. It's just a massive copy and paste job, since they will just model a chunk of something and duplicate it. Creating each bit independently in a modeling program is just too much work.

Other games that use a hybrid system (Doom3/Quake4/UT*) you will notice that the majority of the large structures are still built of brushes, and only details are models. All unique architecture is built from brushes and you will see some repetitive models scattered around.

In the end though, vertexes are vertexes, polygons are polygons. Your video card doesn't care what they were built from. The only person who should care is you, the level designer, since how you get to the end result can either mean a simple solution or a trip through hell because you chose the wrong tool for the job.

[seremtan]

very true, though i get frustrated with brushes because of things like the 'convex rule', and large complex shapes that aren't amenable to a patch/displacement solution need to be tri-souped, and even that doesn't always get you the result you want

a 3D that combines model-style flexibility with BSP editor-style ease of texturing would be pretty awesome. there's no shortage of sandbox-style drag'n'drop editors out there

[a13n]

Here is an in-game shot.

There were a few "impossible" leaks just after the import but they were solved in a few minutes.
There were a few vis errors but they were sovled by cutting or merging the suspicious brushes manually.

All the vertice are snapped to grid 1 by the hand of milkshape.
There are no gaps nor overlappings.

[Kat]

It's 'nice' and all, but you know, I was expecting something rather more complicated as a map, which *would* warrent the use of the method you've been speaking of, but you've got nothing there that couldn't be built from brushwork from the get go; I mean it literally looks like you created the outer core building, duplicated it down the middle, flipped that and jiggled the innards a little bit to make it look like you modelled the whole thing a section at a time.

btw, I hope those aren't your final textures otherwise I can certainly see why UVWmapping was a doddle to do!

[a13n]

UVW is not a problem because I don't set it up at all in gmax.
The level can be more complex.
But I've just finished the basic floor and wall part.

Because the base model in gmax is always in tune with final brushes, it is quite easy to add nonsolid details around them as a md3.

[MaxGaMin]

Thanks, a13n.
You're definitely the true communitist! :icon25:
You should be a moderator.
Please write a tutorial on how those steps are proceeded if I may ask.

[dnky]

...or you could just go to quake3bits.com and see how models can be used by people who open their eyes....

[seremtan]

well that's... disappointing

[a13n]

@Kat & MaxGaMin
This method has not been sophiscated nor matured yet.
I'll do my best, though.

One more note on this method.
Because radiant cannot deal with floating point for brushes, the imported model(md3) in milkshape should be scaled as large as possible before exporting as a map file.
As a result detailed or complicated geometry tends to be required to be larger than it never should.
But there is a workaround for this.
Namely q3map2's scale feature.
Because bsp can deal with floating point, the original larger geometry can be scaled down after final compile though appropriate entity placement is required.
At least it could break through the limitation of radiant.

[Kat]

....At least it could break through the limitation of radiant.

So you're now adding a forth step to the process of producing a map?!

Ok, if you're having "fun" with this, then fair enough, each to his own and floaty boats and things, but trying to push this as a 'legit' working method is just pure insanity as each application and each step introduces a whole host of potential issues that you've been lucky enough not to have hit... yet.

[dnky]

Is there a 'newbs beware' health warning that can be added to threads

[a13n]

Call me or this method anything you want.

The whole process might be overwhelming but the most demanding phase only lies in q3radiant, namely leak hunting, which should be prepared carefully in advance.
As far as I've experienced so far there are more advantages than disadvantages.
The most beneficial thing is that we can make full use of max's powerful tools such as spacing tool, which makes trial and error, as it were, dynamic level planing far much easier.

[Kat]

Call me or this method anything you want.

The whole process might be overwhelming but the most demanding phase only lies in q3radiant, namely leak hunting, which should be prepared carefully in advance.
As far as I've experienced so far there are more advantages than disadvantages.
The most beneficial thing is that we can make full use of max's powerful tools such as spacing tool, which makes trial and error, as it were, dynamic level planing far much easier.

Please tell me you meant G 'max' and not 3DS 'Max'!? If you meant that latter then all I can say is OMG.