Game Development Community

Specifications & Features of a New Torque Mapping Tool

by Scott Peal · in Torque Game Engine · 06/15/2004 (11:04 am) · 121 replies

This thread is dedicated to defining the specifications and features needed for a new mapping tool for Torque.

If you do not believe that there is a need for a new mapping tool, then please do not voice your opinions here. This thread is for those of use that already believe we need a new tool.

When you list your specification or feature request please identify the category that it falls in:

1.0 Overview
2.0 GUI layout
3.0 Import/Export
4.0 Graphics capabilities
5.0 Scripting/Plugins

Categories and sub-categories can be added by this group.

Original thread started here www.garagegames.com/mg/forums/result.thread.php?qt=19141
Page «Previous 1 2 3 4 5 6 7 Last »
#1
06/15/2004 (11:12 am)
--Import Export
----Ability to have all 3 forms of mapping. (Terrin Manipulation, Interior Creation, Static Object/Model/Organic Object Importation.
----Ability to edit regular .map file formats so you can use it for all .map based games.

--GUI Layout
---- Ability to theme/skin/customize your work area, similier to Macromedia's programs where you can hide certain toolbars and such.
---- Ability to customize the blocks according to the game's foot/meter scaling.

--Scripting/Plugins
----Ability to make a plugin taht will customize anything and everything. Inclouding adding new terrein, exporting abilities, and new ui's.
----Ability to convert a .fgd file or quark fgd equivelint to the games fgd equivelint.
#2
06/15/2004 (11:16 am)
I posted this in the other thread, but can't hurt to post it here, too.
http://www.garagegames.com/mg/forums/result.thread.php?qt=8752

There are a bunch of suggestions in that thread.

*edit to make link*
#3
06/15/2004 (1:44 pm)
4.0 Graphics capabilities

4.1 Prefab system, where you can add a prefab optionally as:
- a copy, that can be changed;
- an instance: you can only change the prefab model file and refresh the map file(s) where it's used.
...and an easy way to switch between both (turn a copy into an instance and vice versa).

4.2 Ability to manipulate vertices directly. The editor must allow me to move vertices to wherever I want, like Hammer does.
#4
06/15/2004 (2:49 pm)
I'm sorry if I sound like I'm banging on about Ogre3d again and again, but this info belongs here I think :)

[Disclaimer: I'm doing this from memory]

Ogre3d has an xml polysoup intermediate model. While this greatly increases the size of a typical 3ds/max/lightwave/blender/etc object it has a number of advantages.

All the bones, polys, UV mapping etc are held in an xml file.
This can be trivially transformed with xml stylesheets to do much in the way of post processing - though admittedly that is not used much, but I found it helpful to generate material files from the wings3d exporter.

Ogre even has open source exporters for
* 3ds max,
* Milkshape
* Wings3D
* Blender
* Maya
* Lightwave
www.ogre3d.org/docs/manual/manual_34.html

"All that would be required" (famous last words) would be a version of "OgreXMLConverter" that spits out .MAP, which would be of more general use than straight to .DIF and .DTS
www.ogre3d.org/docs/manual/manual_35.html
It has also features such as scaling and auto LOD generation

Okay, it's not an integrated solution or a modelling application but may take less time to leverage existing code out there, and make things easier overall for both projects.

There would however be concerns distributing LGPL code perhaps.

I've not discussed this with Steve Streeting (irc nick Sinbad on #ogre3d over on freenode irc) so I don't know how he might feel about a commercial project utilising ogre tools or how GG employees would feel using LGPLed works.

Actual use of the Ogre toolchain isn't quite my point though, I'm just discussing how another project that I am familiar with implemets exporting models, and importing them into their own customised format.

model exporter -> intermediate format -> TGE format[s]

Finally having the ability to seperate the exporter from the final TGE creation allows developers freedom to write their own exporters, or even to procedurally create "organic", etc, models.
#5
06/15/2004 (2:51 pm)
These are extrapolated from Lee's post in the other thread:

2.1 Very easy user interface
2.2 Make hollow should name new polys to North, south, top etc. Not poly1, poly2
2.3 Nodes and plains should snap together
2.4 Set an origin point for each poly and do the maths from there, less chance for strange realignment
2.5 Automatically nullify and snap faces that are within X units of each other.
2.6 Do some serious poly checking, dragging a node past another one makes the poly unselectable
2.7 Less changing between modes
#6
06/15/2004 (5:29 pm)
@Lee: the fact that it's written in C# doesnt mean it will be usable in Linux. It definetly won't if you use WinForms.
#7
06/16/2004 (3:26 am)
1) it has to run on Linux and MAC :)
#8
06/16/2004 (4:21 am)
Quote:You cannot write one code base using system stuff without rewriting parts of it for each OS.
Before anybody says a word about that comment, yes it IS possible, but you end up with a lot more coding and a rather untuned app.
#9
06/16/2004 (4:35 am)
...
#10
06/16/2004 (5:17 am)
Out of curiosity, what percentage of users of the tool (not the game) would be Windows verses Linux, verses MAC?

If the majority are Windows users then I vote for C#.

Also, to my knowledge WinForms will work in Linux via .NET from articles that I read, but I have never tried it before. Has anyone else tried?
#11
06/16/2004 (7:50 am)
Quote:
Out of curiosity, what percentage of users of the tool (not the game) would be Windows verses Linux, verses MAC?
A more important question to me is:
how many native map editors are available on windows versus Linux, versus MAC?
I'd say "a dozen" - "zero" - "zero" :P

Therefore wxwindows + OpenGL sounds good to me, too... ;)
#12
06/16/2004 (8:27 am)
Cart before the horse, guys. Finish setting up your features list/design doc, then find out who's willing to work with you. Then settle on implementation details, like language choice.

If you attract some C# programmers, great. But realistically, in this community you'll probably get more interested developers with C++ or python experience.
#13
06/16/2004 (9:42 am)
Two questions: Since Torque can handle Python (thanks to Josh Ritter), can much of QuArK be ported over to Torque, as long as the UI and graphics engine is used instead?

Also, QuArK++ seems to be back in action. I wonder if since it's to be cross-platform, that it may be easier to join forces with them?

Of course, neither of those are the "one size fits all" solution. I'm not so sure that such a thing can effectively happen with the CSG constraints anyway?

-Eric F
#14
06/16/2004 (10:02 am)
I think Brian and I decided on C#, Although I do not know much C#, i've been fooling around and so far i've learned alot. Right now, imho what we need the msot help with is coding the new .DMF (Dynamix Map File (if Jeff and his associates allow us to use dynamix)). Reguarding mac support, i do not have a mac computer on hand atm. (If anyone was selling a G4, monitor, keyboard and mouse, i'm sure i could dig up some money to buy it off ya.) We will be using SharpGL (OpenGL, in C#) for the editor.

-Chris
--Darkness Studios
#15
06/16/2004 (11:13 am)
Vivendi and co. own the Dynamix name, not Jeff. I would suggest choosing a file format and NOT explaining what it stands for. :)
#16
06/16/2004 (11:19 am)
Quote:1. Write it in C# so everyone can use it.

If I were working on such a project, it would be written on top of Torque, thus making it
A) Cross-platform.
B) Render lighting, static meshes, entities, etc. exactly as they would appear in-game.
C) It would be written in C++ (obviously) and TorqueScript
#17
06/16/2004 (1:15 pm)
An added benefit of Alex S's suggestion is that the TGERad code could be integrated into the in-engine lighting algorithm, thus allowing very realistic lighting.

(Why does it always seem that I post after Alex?)

I'll try to think up some suggestions:

2/4. UV texture projections... select a set of brushes/faces, then apply planar map. Also allow sphere and cylinder mappings.
2. UV Texture coord editor more like Milkshape/Maya/unwrap3d. This allows you to see the coord of all selected faces, rather than just one at a time. Textures align much quicker this way.
2/4. Quark has _awesome_ duplicators. Get as much of that as possible... most especially extrude along path (allows for quick tunnels and wicked-cool-shaped rooms easily).

As far as the DMF filename extension goes, it could be "Da Map Format" :) Or "TMF" for "Torque Map Format" (also "The Map Format")
#18
06/16/2004 (1:23 pm)
I can also do realtime lighting in The editor by mimiking the lights, trust me its on the agenda, as for SharpGL i've found it worked perfect for me, not slow, rather fast. But i'm always open for sugestions and new ideas, so is Brian.
#19
06/17/2004 (11:14 am)
I've been using VS.Net
#20
06/17/2004 (11:58 am)
C# ? hrm... that is all I have been doing for the past couple of years ;) just started to re-write the local ciber branches website using the portal starter kit from asp.net. Even wrote my own TreeView control, can't wait for .NET 2.0 to hit the mainstream.. no need to roll half of my own controls.

-Ron
Page «Previous 1 2 3 4 5 6 7 Last »