Can't really see any benefit in this idea though. Sounds like 'mapping the hard way' to me.a13n wrote:1stly I made a simple cylinder in gmax then deleted the meshes except the top one.
Q3Radiant Map Exporter by Milkshape 3D [DLPUF]
Re: Q3Radiant Map Exporter by Milkshape 3D
He mentioned something about gmax in his first post so that's most likely what he meant:
[color=#FFFFFF][url=http://maps.rcmd.org]my FPS maps[/url][/color]
Re: Q3Radiant Map Exporter by Milkshape 3D
'Alen' has a history of confusing posts so no, he may not be talking about Gmax, hense my comment.dichtfux wrote:He mentioned something about gmax in his first post so that's most likely what he meant:
Can't really see any benefit in this idea though. Sounds like 'mapping the hard way' to me.a13n wrote:1stly I made a simple cylinder in gmax then deleted the meshes except the top one.
Mate seriously, you *really* need to stop and think about this. If someone has access to 3DS Max they should be using ASE models and simply exporting out to that format and then boxing the resulting models in a caulk hull.a13n wrote:@Kat
Acutally any max or app will do as long as it can deal with splines effectively and can pass the final meshes to milkshape in any form.
My next map will be a cpma-oriented map.
If they're using Gmax and doing nothing more complex then you've shown here then you can use the Tempest plugin and compile a BSP/map file directly from that.
Both of those methods mean you're working directly with fully built meshes that have UVWmapping applied to them *at source* which can be used *directly* in editor/game *as is*. That's two tools and two processes; model and UVW in a 3D app and then import, box and compile in Radiant.
If after reading this you *still* think that using four tools and as many processes (incidently where is UVWmapping? Are you doing that in Radiant?);
1) building in gmax, exporting to MD3
2) importing MD3, resizing, exporting to .map
3) importing .map file, compiling
4) scaling via compile, final output
5) rinse and repeat 4) until you get the proportions correct relative the gameplay and entities.
...is a 'good' thing then I don't know what to say else to say really except to agree with dnky about creating a "not noob friendly" warning sticker to place in threads like these which are woefully misguided, albeit with good intentions.
I'm really surprised by your lengthy joke again and again. :icon30:
By the way you can import/export continuous "large" geometries at once.
Beyond that milkshape automatically "func_group"s them based on the mesh group.
So in most cases import/export count should be low and exported brushes should be quite easy to handle unless something unexpected happens to map file.
By the way you can import/export continuous "large" geometries at once.
Beyond that milkshape automatically "func_group"s them based on the mesh group.
So in most cases import/export count should be low and exported brushes should be quite easy to handle unless something unexpected happens to map file.
I still don't think you're getting it. Why are you adding all these complex import/export steps to your workflow 3-4 times between different applications when just a single export step will do the exact same thing? Just seems to us as if you are deliberately making things more difficult without any benefit to the appearance, performance or ease of mapping.
I mean, if you want to make your life harder as a learning experience, then by all means no one will stop you. But to post on a forum like it's some sort of tutorial that everyone including beginner mappers should try is pure folly.
Until you've actually provided a tried and true method that yields better results, this is strictly an experimental technique at best. You haven't yet explored possible limitations of your method so for all you know, this may not be feasible at all.
I mean, if you want to make your life harder as a learning experience, then by all means no one will stop you. But to post on a forum like it's some sort of tutorial that everyone including beginner mappers should try is pure folly.
Until you've actually provided a tried and true method that yields better results, this is strictly an experimental technique at best. You haven't yet explored possible limitations of your method so for all you know, this may not be feasible at all.
[size=85][url=http://gtkradiant.com]GtkRadiant[/url] | [url=http://q3map2.robotrenegade.com]Q3Map2[/url] | [url=http://q3map2.robotrenegade.com/docs/shader_manual/]Shader Manual[/url][/size]
No.
They are, at least, on grid 1.
Almost everything goes well though some retouches are required.
I name this method "Dynamic Level Planing Ultra Fast(TM)"
In short D.L.P.U.F(dee el pAf).
They are, at least, on grid 1.
Almost everything goes well though some retouches are required.
I name this method "Dynamic Level Planing Ultra Fast(TM)"
In short D.L.P.U.F(dee el pAf).
Last edited by a13n on Sun Mar 18, 2007 3:31 am, edited 1 time in total.
If grid 1 is too hard-boiled for you, you can shift to grid 2 by setting larger scale in milkshape, which would result in less unexplainable leaks at the expense of deeper consideration of final scaling of geometry, lightgrid and lightmap.
In that case you have to be more careful to entity placement.
In that case you have to be more careful to entity placement.
So wait..! You mean you have to fix a shit load of "unexplained" leaks as well as all the other stuff you have to do to get this to work?a13n wrote:If grid 1 is too hard-boiled for you, you can shift to grid 2 by setting larger scale in milkshape, which would result in less unexplainable leaks at the expense of deeper consideration of final scaling of geometry, lightgrid and lightmap.
In that case you have to be more careful to entity placement.
Hmmm I wonder what could possibly be causing the compiler to find leaks like that? Could it be that, oh I don't know, your map actually has leaks due to the method you're using!? :icon22:
It's funny but when I build maps I very rarely have *any* leaks never mind "mysterious" ones.
Actually there were a few leaks in my map(grid 1).
At 1st they seemed to be unexplainable.
But after subtle struggles they turned out to have some kind of law.
I'll list up the 2 reasons once it is surely proved to be the ones.
I need more tests which takes time.
By the way I'll post yet another related method later, which would likely to be more acceptable to everyone.
At 1st they seemed to be unexplainable.
But after subtle struggles they turned out to have some kind of law.
I'll list up the 2 reasons once it is surely proved to be the ones.
I need more tests which takes time.
By the way I'll post yet another related method later, which would likely to be more acceptable to everyone.
Yes... build a map correctly and you don't get any. Simple really.a13n wrote:Actually there were a few leaks in my map(grid 1).
At 1st they seemed to be unexplainable.
But after subtle struggles they turned out to have some kind of law...
:icon22:
[url=https://www.katsbits.com/tutorials#q3w]Tutorials, tools and resources[/url]
-
+JuggerNaut+
- Posts: 22175
- Joined: Sun Oct 14, 2001 7:00 am
So...you make not just one, but two threads about a new method of mapping? Then when people don't agree with you regarding the usefulness of this method, you ask that it not be judged and tell them to wait for a map?a13n wrote:Judge the new type of gameplay instead of the method itself.
I haven't seen anything at all about gameplay in these threads.
If you don't want people to judge your method, then I see no reason to leave these threads open.
Feel free to make a new thread when you have a map and want people to judge gameplay.