Let's make a new tool for DIF?

#61 Mark

I just used BSP & OcTree as an example, they are something most everyone has heard of. You would definetly want to take some time and evaluate all the different structures.

The modeler would be responsible for placing portals, occluders and other helper objects. The idea I was trying to get across is that the intermediate format contains higher level information that the post processor uses to generate collision and visibility structures.

A simple intermediate format increases the chance for exporters to exist for different modeling programs on all different platforms.

#62

Quote:
elite few. We are doing our best, but we can;'t defy the laws of physics.

-Jeff "Scotty" Tunnell GG

Aye, Scotty, :-).

Being a blender user long before I was a torque user and passionately disliking QuArK's UI ... again when I started using it for interiors, I wrote a basic map exporter for blender. It was very obvious after spending some time on it that its not a simple matter of creating a model in polygons and exporting it.

Now, I realize no one really knows me here in this community, but people who have much more visibility here are saying the same thing I saw. Polygon modeling and BSP modeling are two separate things.

Yes, you can make a utility that will create a BSP based model from a polygon model within certain limitations. The big problem that stopped me from progressing with my blender map exporter is that you have to pick one of two roads.

Either you let the user model using arbitrary polygons to build the model and then somehow try to generate the BSP model from that or you need to recreate all the features (possibly more if you're actually going to improve on them) that the BSP editors already have.

Both have their issues. The first eliminates or greatly hinders the ability to optimize the interiors generated in that fashion which is likely to mean a drop in frame rate for the game. The second means you will either not have a very easy to use editor or you'll end up reinventing/reimplementing at least all of the features the current map editors have. Also, this second method basically means you're using a BSP modeling program again which will end up replacing many of the native modeler's features.

Note, that I'm not saying this is impossible to do. I'm just saying that it is much more involved than it looks at first glance and has some significant issues to over come if the project is going to succeed. I decided it was just simpler, cheaper, faster and better for our game to come to terms with QuArK even though only a few of us use windoze with any regularity.

#63 Mike J and I have been talking about this idea for a few weeks now. We wouldn't be generating the BSP (or whatever collison method) using an arbitary poly mesh.

You would model your interior (keeping polys with in the realm of feasibility), then using boxes or other simple low poly shapes you would create collision objects, portals, sectors etc that would be used to create the BSP, octree or whatever it ends up using.

This process would add steps to the workflow process because you would need to create the interior, setup the collison objects and sectors, set up your lighting and entities and then export the information.

Then a processor somewhat like map2DIF would compile the interior and you would load it into the in engine editor the same way you do a DIF file.

We already know how much work it will be (if it was easy someone else would have done it by now) we're working on the feasibility aspect of this and wondering if other artists/developers are willing to do the extra steps it takes in the work flow process?

Anyone?

#64 The problem with quark is it's user-unfriendliness. It's like adobe products, you've got to know it inside out before you can make it work properly. The main problem areas I've encountered so far are:-

1. Make hollow should name new polys to North, south, top etc. Not poly1, poly2
2. Nodes and plains should snap together, the grid settings are useless
3. Set an origin point for each poly and do the maths from there, less chance for strange realignment
4. Automatically nullify and snap faces that are within X units of each other.
5. Do some serious poly checking, dragging a node past anothe one makes the poly unselectable
6. The GUI sucks. It's like windows 3.1
7. Way too much changing between modes
8. The fact it's so easy to wreck a model with one command, some commands are really dangerous like SNAP TO GRID! Fix it!

Thats a bit of a rant, I do apologise to the quark boys. It needs some serious end user changes, I gues most of there time is spent getting new games to work but they should go back and redo the interface, grid and snapping from scratch cos it's unreliable. It's not the program thats bad, it's the interface and it's lack of tuning.

I'd do all the interface work for a new app if someone else understands BSP and the maths involved. I'd use C# cos thats windows, linux and shortly MAC compatible so everyone could use it.

#65 Wow, how did I miss this thread?

I think everyone is misunderstanding the problems presented here (on both sides). Let me try to explain...

CSG editors are a pain to use and the dif format is very limited, but only when you're trying to push the limits of CSG modeling. Modeling in mesh objects is clearly preferred, but this introduces performance or pipeline issues (create collision objects).

Using mesh objects certainly does work, but don't be fooled - converting mesh objects into levels won't be a magical process. When converting complex objects you'll always be forced into one of two situations; loose performance due to massive collision calculations, or create separate collision objects.


IMO the two problems facing dif format are:

-Lack of support for complex objects.
-Poor lighting on rounded objects.

Using a combination of dif and dts objects allows for complex/rounded objects with proper lighting and will solve 99% of other modeling problems. Again this is my opinion, but I feel that dif + dts is one of the better level modeling environments out there. I can achieve the same results I hoped to accomplish with Xdif using dif + dts + Lighting Pack.

Example of dif/dts combination:



Hope this helps.

-John Kabus

#66 I'm not misunderstanding the problem. I know that faces need to flat and the fewer the better. My gripe is that the editors are not user friendly and they could be. I wrote a Drag and Drop warehouse stock management utility, thats what you call a GUI challenge!
There is no reason why the GUI could not be a lot more friendly but still powerful, abstraction is the key. I'm sure that if the Quark boys started over they would make a much more reliable editor, it's been knocking around for 6 or so years I think and I'm guessing it's using the same code-base. Refactoring is a lot easier and quicker than people think.
The key feature they need to sort out is not related to DTS, it's the snapping problem and that objects disappear when the vertices are dragged past each other.
I think another key feature would be to have a more cad approach, top view, select wall brusg, draw lines, have the app do the snapping and plane hiding, I used to use an editor like this years ago, can't remember what game it was for though, might have been blood!

#67 @John: Wouldn't it be possible to go the Unreal way here and have a "fake" .DTS positioning in Quark (or whatever editor you prefer) via an entity or such (Quark supports ASE loading right) which then translates the coords to the engine and automatically places the .DTS objects in the world??

#68 @Lee: Please come and help us with a new tool. I also am willing to write the code/GUI in C# if I can get some help with the graphics methods and formulas. We can Sourceforge it if you want.
www.garagegames.com/mg/forums/result.thread.php?qt=19200

#69 Jorgen,

Yes and no. You can do it, but the entities would look like pink boxes (like player/env entities in HalfLife), so orientation would be very difficult.

You're definitely on the right track though, an entity like in-editor prefab is a concept that I've been pushing for in Cshop. It looks like it may be supported soon, but due to other problems with Cshop I'm unsure how useful it will be.

#70 Hey John, how do you feel about creating a whole new level format and working with a team whos also creating an editor?

#71 @John: CShop seems like a nice program but the first couple of times I tried the 4.0 demo it really flaked on me so .. first impressions last I guess
I've really taken to Quark because of the scripting functionality (which I intend to plunge into this summer) which really makes it ahead of the rest of the level editors out there.
Anyhoo, pink boxes would to me be a step forward, nothing bugging me right now as much as placing .dts objects withing buildings in the worldeditor.

#72 I've never looked at the "behind the scenes" of dts, but doesn't it already support polysoup and collision meshes? All it would need is a gradual distance culling instead of the "now you see it, now you don't" it uses now?

#73

Quote:@Josh (Ritter): Do you have some special middleware to get DOOM builder -> Quark working the way you are describing??

Yes, it's called dtoq2 ... as it generates brushes that can be loaded into Quark, it's applicable. It also has a pretty cool pathnode generation scheme. I hate hand editing stuff like that.

You can view the sources here. As you can see by the commit history, it's quite stable.

map.c and the minibsp.c (which is in toolscommon) are the most interesting bits... dtoq2 should compile from the CVS or the Source Preview #1 available on our
Sourceforge Site

dtoq2 is also how we extrude terrain...

I hope this helps... if you do something with it, lemme know... otherwise, please don't, if you catch my drift ;)

-Josh Ritter
Prairie Games

#74 JOSH@ Do you fancy putting all this together and a little tutorial as a resource ;)

#75

Quote:I hope this helps... if you do something with it, lemme know... otherwise, please don't, if you catch my drift ;)

Got it ;P

#76 Chris,

Right now I'm swamped with the Lighting Pack and 'future' development (with some consulting thrown in), sorry.

Really make sure that a new interior format/modeler is what you (as a group) want to work on. I personally think having a 'TorqueEd' is an excellent idea, especially if the source was open to all sdk owners, but who will maintain the source after the release? I certainly don't speak for GG, but I doubt they want to support a community declared/designed/developed product.

When changes are needed who will decide the direction of the 'official' source (consider the current 'poly soup' vs CSG argument)? How many editor offshoots will we end up with? I see this causing a lot of confusion for new community members.

Again I would like to see a TorqueEd, but do consider the management issues.


Jorgen,

Adding the dts entities will require additions to map2dif, interior.cc, and interiorInstance.cc. You'll get an idea of how it's done by checking out the code that handles dynamic light and waypoint entities - you'll need to follow a similar path. The difference is you'll be dynamically creating TSStatic objects in interior::onAdd (easiest place). This should get you started (more info will need to be discussed in the sdk forums).


Thomas,

Dts already supports meshes and collision objects; however significant changes are needed for use as interior objects. For one the maximum number of collision objects is nine, however dts objects are ideal for adding detail to existing dif interiors.


Josh,

Very cool stuff. That setup makes for very rapid level development.

-John

#77 I will be happy to support the source.

#78 As a side note talking about modelling format changes and collision have a look at this thread.