• Advertisement

Archived

This topic is now archived and is closed to further replies.

brush based editor, or something better??

This topic is 5486 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

hey guys, been a bit burnt out on coding lately. so i downloaded qrad and have been building a new map for soldier of fortune 2. its called Iraqi bunker assault, and is coming along nicely. (for any sof2 servers out there ill post a link when its done) using this tool has me thinking. i like the brush based system that qrad uses, and its pretty obvious what is going on in the background. so long story short. would any of you recommend this type of brush based system for base geometry? (obviously supplemented with the ability to import models as well) or is there another solid geometry system i havent seen that puts the brush based system to shame? comments, advice? Dreddnafious Maelstrom "If I have seen further, it was by standing on the shoulders of Giants" Sir Isaac Newton

Share this post


Link to post
Share on other sites
Advertisement
I think that you have two options really when you''re talking about geometry construction: the q3radiant/Hammer way, and the 3DS Max/Maya way. Both have their advantages. The brush-based system of q3radiant and Hammer Editor is flexible, pretty easy to manage, and allows for CSG (Carve, etc.). The 3DS Max/Maya method deals primarily with meshes, and is suited to creating both models and game environments (gmax is nice example of this).

Personally, I chose the q3radiant/Hammer Editor system, because I have experience with Hammer Editor and q3radiant, and I only wanted to deal with level geometry, not models. Also, I''ve never used 3DS Max, so I couldn''t really base my program on a program I''ve never used (I''m going to get a copy soon, I need some models ). My brush-based level editor is called DarkVertex, check the sig.

Hope this helps some...



Coding Stuff ->  [ iNsAn1tY Games | DarkVertex | How To Do CSG | Direct3D Vs. OpenGL | Google ]
Fun Stuff    ->  [ Evil T-Shirts | Stick-Based Comedy | You''re Already Here | The Best Film Reviews ]

Share this post


Link to post
Share on other sites
My friend made a short video in 3DSMax for a school project. He had to make a castle as part of the setting. He said that doing buildings by drawing the actual polygons was a huge pain, and that a brush-based map editor would be much better. For FPS maps, the geometry would mostly be simple, and so it would be easier to draw brushes than actual triangles. If you wanted something like q3''s statues of the bots in some maps, then importing models would make this much easier.
On the other hand, think of when you want to turn these maps into geometry. If you made the map in 3DSMax, it would already be geometry. With brushes, you would have to write an app to do it.

Proceeding on a brutal rampage is the obvious choice.

Share this post


Link to post
Share on other sites
That seems to be ignoring the fact the max has quite capable geometry like boxes, cylindes, cones etc. so you don''t actually need to ''paint'' triangles until the very end stages.

I''m in two minds about whether poly based or brush-based geometries are better. The hardest thing about using max is actually getting the texturing right, but that''s probably because I suck at modelling

With a poly-soup level you don''t get any guarantees about the geometry, there could easily be gaps etc. which you can avoid when using brushes.

Possibly some sort of combined editor would work really well (I think things like GtkRadiant and worldcraft are headed this way), which would be highly competent at CSG with brushes and also provide low-level polygon editing.

Of course a lot of it depends on how your engine works, if you need a solid leaf BSP then brushes will be the way to go, otherwise it doesn''t really matter.

Share this post


Link to post
Share on other sites
in my editor i use the 3ds max way
why? i think it is easy to use

of course it is a lot of work in 3dsmax to create complex buildings but on the other hand with a bit of work you can implement complex tools to fit all your needs

for example create a large outdoor terrain in radiant/worldcraft
damn lot of work really

in my editor i use the plane tool with x,y segments and paste it

now all you have to do is modifying your vertices

i think that spares a lot of work doesn t it?

another nice feature would be for example
choose a texture go to a u,v map editor
and past your polygons in 2d to create a palett
now click into the front view and paste your construction
voila nice looking facade


Share this post


Link to post
Share on other sites
well, when i was debating it in my mind, i think it all really comes down to polygons anyway. what i had in mind was a similar gui to qrad. a large gdi based page to draw on, and a small render window to see your effects in realtime. either way it will be polygon based. say for example i draw a square. its just really four quads in a cube shape. then i press the hollow key, now its just 24 quads in a cube shape. ill still make my models in milkshape and just build an importer that lets me get the model and place it, as well as allow the exporting of a detail file to hold additional info.

it would probably also be good to include a prefab option(which is quite handy in qrad. as well as the ability to slect an individual face and apply and manipulate a texture on it. (cant figure out how to do this in qrad without adding additional geometry. of course it would seem right to go ahead and precalculate bounding boxes and spheres and be able to toggle them and manipulate them as well.

ok, well thanks for the ideas. if you know of any other techniques or have any ideas that would be cool to implement feel free to post it.

@ insan1ty, im going to check yours out right now. thx

*edit, just read your csg article, funny and informative, thanks.

[edited by - Dreddnafious Maelstrom on February 8, 2003 4:33:03 PM]

Share this post


Link to post
Share on other sites
Heh, glad you liked the CSG article, but if you were under the impression I wrote it, I didn''t . I just found it on the net, found it extremely useful, and wanted to make sure other people saw it.

btw, I''m putting some new DarkVertex screenshots up tonight, from the newest version, the one I''m working on now...



Coding Stuff ->  [ iNsAn1tY Games | DarkVertex | How To Do CSG | Direct3D Vs. OpenGL | Google ]
Fun Stuff    ->  [ Evil T-Shirts | Stick-Based Comedy | You''re Already Here | The Best Film Reviews ]

Share this post


Link to post
Share on other sites
is it just me or is setting up a correct grid in all 4 views the hardest part of creating the editor :D

Share this post


Link to post
Share on other sites
@ Basiror, hehe, i wouldnt know yet, but im thinking about doing mine in VB, just to simplify the whole project. im not that great with MFC, and all we are really talking about in the end is a utility that writes some data to disk.

im still in the planning stage of mine, but i can tell you and insan1ty have already put a bunch of work in. of course if i do it in VB then i have to jack with all the COM stuff. ahhh man, im still trying to get this right in my head.

Share this post


Link to post
Share on other sites
Hey insanity , and don''t forget we where supposed to look dark vertex in action b4 a few months . However , if ur on a redesign phase just keep up , it''s looking cool .

Share this post


Link to post
Share on other sites
Joe, thanks again. I'll have a "still in progress" version in the next two weeks, I promise.

Bas, I just implemented grids again, and I still couldn't find a better system than the crappy one I was using before. All I'm doing is checking the window's state, deciding whether to create a grid in the x = 0, y = 0 or z = 0 plane, then just creating a grid around the user's current position. I do a little math to ensure that the grid doesn't move just with the user, then I just render it. I'm still doing it every frame. If you've thought up a better system, I'd love to hear it...

By the way, Bas, if it isn't too much trouble, could you email me those MFC/OpenGL documents? The programming world is moving away from C (which has been my primary language since I learnt it about three or four years ago), and towards C++ and MFC. I'm going to have to learn those two sometime, so I might as well start now . I'm going looking for some C++ and MFC books this week or next, any suggestions?



Coding Stuff ->  [ iNsAn1tY Games | DarkVertex | How To Do CSG | Direct3D Vs. OpenGL | Google ]
Fun Stuff    ->  [ Evil T-Shirts | Stick-Based Comedy | You're Already Here | The Best Film Reviews ]


[edited by - iNsAn1tY on February 9, 2003 9:03:57 PM]

Share this post


Link to post
Share on other sites
get
Programming Windows with MFC Second Edition
from Jeff Prosise

the best mfc book i could find i use it as a references

www.codeproject.com
www.codeguru.com

those sites have fantastic code samples to look at


ill send you the files later i need to go now cause we get OIL before bush invades iraq *G*


maybe you want to have a look at the creating 3d tools tut on gamedev thats what i have used to get started with mfc

as long as you use the class wizzard you shouldn t have a problem with control handling


about the grid

i fucking hate the grid what i am doing is get the scroll pos 0-<2^16/2
doesn t work for high values somehow

then i get the width/2 of the view
subtract it from the scroll possitions and then check the result

16 is grid space
d=min.x/16-(int)(min.x/16);
nx=(int)(min.x/16);
if(d>=0.5)
nx++;

once you have got that for Y as well you get the distance between screen center of the view and nx / ny
now check whether it is greater than >0 and < screenwidth/screenheight

and now render

you can use this procedure to perform this snap to grid feature as well but you need to take care of the zoom modi

1,2,4,8,16,32,64,128,256,512,1024,2048,

if there s mistake in my theory please point it out i thought about this the entire day
til now i have fixed all the problems mfc caused when using opengl
slow progress but there s nothing worse than a bug right at the beginning that ruins all the effort you put into your app

Share this post


Link to post
Share on other sites
Well, in DarkVertex, there are five zoom modes, which you switch between using a window menu (I''d use the mouse wheel, but there''s just no support for it).



Coding Stuff ->  [ iNsAn1tY Games | DarkVertex | How To Do CSG | Direct3D Vs. OpenGL | Google ]
Fun Stuff    ->  [ Evil T-Shirts | Stick-Based Comedy | You''re Already Here | The Best Film Reviews ]

Share this post


Link to post
Share on other sites
if you use progressiv zoom you will get trouble with your grid it looks ugly
download worldcraft and test it hehe

Share this post


Link to post
Share on other sites
What do you mean ? I thought worldcraft did not perform smooth zooming . I think there is a limited number of zoom modes available . (unless i am missing an option wich i could enable or disable) .

Share this post


Link to post
Share on other sites
I have WorldCraft, and it uses the mouse wheel to smooth-zoom. It''s a good system, but I can''t use it, because VB doesn''t support the mouse wheel. Anyway, I designed the grid so it wouldn''t look too bad zoomed...



Coding Stuff ->  [ iNsAn1tY Games | DarkVertex | How To Do CSG | Direct3D Vs. OpenGL | Google ]
Fun Stuff    ->  [ Evil T-Shirts | Stick-Based Comedy | You''re Already Here | The Best Film Reviews ]

Share this post


Link to post
Share on other sites

  • Advertisement