Free Allegiance Forums

Development progress on ATM II is going well. Most of the 'middleware' stuff is done and i'm now working on the 3D editing interface.

This is where i'm not sure how to do this mainly because i'm not a 3D artist at all so I don't know the "rules & common usages" in this field.

1st let me recap what AMT II is:

AMT foundation is a 3D model viewer. It's like MDLView but with editing features. It's not a 3D modeler since you can't directly edit points & faces (meshes) but you can import them and combine them. For instance if you have 'building bocks' for a faction , you can combine them in AMT II to form a complete alleg models.

Then you can add and edit Alleg specific datas in ATM II. These datas are generically called 'Hard Points' (HP there after).

There are various types of HP, each type corresponding to a specific Alleg usage.

As of today, HP types are:

- Lights
- Mount positions: for weapons & turrets
- Launching bays
- Docking bays (called "garages" in Alleg)
- Effect positions

All of these HP types are simply defined by a 3D position (a point) and a name.
Some of these types have extra informations such as an orientation or a color for instance.
Finally the garage type is quite complex since it's a collection of planes.

Now the 1st question come to ergonomics of editing these HP.

What would be the most efficient and yet simple way of editing the position of a HP ? Other way of asking is how to define and move a point in 3D inside a scene ? What's the standard ergonomics here ? (we're talking about User Interface here).

Since some of these HP have also have an orientation, again how to visualize and edit an oriented position ?

Finally, the hardest part: garages (*cough* GT docking bays and AMT1 /tongue.gif" style="vertical-align:middle" emoid=":P" border="0" alt="tongue.gif" />)

A garage in Alleg is defined by 1 to 6 planes. All original Alleg models use 5 planes but the engine support from 1 to 6.

A plane in 3D can be defined by 3 non aligned points and a normal (it's an oriented plane to distinguish on which side of the plane we are)
or by a position (a point) and a direction (the point belongs to the plane and the plane is orthogonal to the direction). Alleg uses this definition.

So a garage plane is also an oriented position like the previous question.

But to ease the editing and positioning of garages, i guess AMTII shouldn't display garage planes as oriented points.

We need a way to visualize the planes and their orientation (aka distinguish sides of the planes). And a way to edit them: move and orient.

For instance as a 1s draft, I rendered the garage planes as transparent squares.



with sides distinguished by color (red & green). The example is cap500 (a carrier).

A ship docks in a garage when ALL the following conditions are met:
- the ship collides with the garage owner (a station or another ship(carrier)). (it's a CVH models collision)
- for each plane garage: the ship is on the 'green' side of the plane and doesn't touch the plane.

As you cannot see in the picture, the planes are actually infinite. What matters is the area "inside" formed by the 5 planes and the mesh.

So how can we visualize and edit these garages ? Should I draw infinite planes ? I lack ideas here /smile.gif" style="vertical-align:middle" emoid=":)" border="0" alt="smile.gif" />

firstly:
allow people to select meshes to use to define positions for things.

e.g. for a light they could select a box and click a convert to light button. the box gets deleted and a light is created where it was located.

secondly:
don't draw the infinite planes - think inside the box, and then draw the box

blue thing with green inset is the model with a green door. little pink boxes are to be lights (select them and convert to lights as mentioned above)
big arrowey thing is a gizmo for moving selected things
see through box on the left defined a door

give the users a box they can move, in the above image the user would move the box along the XYZ axes by clicking and dragging on the RGB arrow gizmo.

each of the faces of the box would be used to define the infinite plane (the face just has to continue along infinitely for it to be an infinite plane).

the user could select the verts in the corners of the box (not shown in image) to change it's shape.

rotation could be handled by a differently shaped gixmo with small arcs on the ends of the right angle bit instead of arrows, dragging them would rotate the selected thin on their axis.

representing things which have a direction as well as a position, i would think use an arrow, base of the arrow is at the position, the tip would be in the direction relative to the base.
could use the same select and convert thing i mentioned for the lights only you would need two objects to define it, one for the base, another for the tip.

an alternative to selecting objects and converting them would be to select verts and place something where they are.

madpeople wrote:QUOTE (madpeople @ Sep 9 2008, 03:47 PM) firstly.

allow people to select meshes to use to define positions for things.

e.g. for a light they could select a box and click a convert to light button. the box gets deleted and a light is created where it was located.

by "select mesh" would it be limited to a whole 'frame' as defined in the .X file or do you want a more dynamic selection that propagate along connected vertices?

Let's take your example picture in .X file format: it could have 6 frames (1 for blue thing , 1 for green inset and 1 for each red boxes). So selecting a frame and converting it to a HP is simple: remove the frame and place a HP at this position. So far so good for me.

But the same picture could be .X file with only 3 frames (1 for blue thing, 1 for green inset and 1 frame for all 4 red boxes). In that case selecting 3rd frame (the 4 red boxes) wouldn't work. So either the artist must go back in his 3D modeler to break the frame into 4 frames OR AMT2 could allow selection of connected vertices by clicking on one of the red boxes. Then only the vertices of this selected box would be removed and converted to a HP.

Is this worth the pain to code or are most 3D modeler outputs generally well structured enough (each logical mesh has it's own 'frame') ?

QUOTE an alternative to selecting objects and converting them would be to select verts and place something where they are.[/quote]

yeah that can be done. I already have the 'selec vert with mouse' code so this would be easy.

QUOTE big arrowey thing is a gizmo for moving selected things[/quote]
So this would be the general tool to move thing around (and rotate too by adding extra 'grips').

Is precise coords editing also needed (input boxes with the 3 coords) or do ppl never bother with numeric values?

QUOTE see through box on the left defined a door[/quote]

hum this is not that simple because the input/output datas are 1 to 6 planes. I"m not sure we can always transform 1 to 6 planes into a box like the one you drawn. Original Alleg models use 5 planes so the 'box' would be 'closed' on one side (the bottom of the docking bay) and infinite toward its opening side.

This could work but I need 3D math experts for this /smile.gif" style="vertical-align:middle" emoid=":)" border="0" alt="smile.gif" /> I need the formulas, given 1 to 6 planes, to compute that 'box' as well its size ("cut the infinity") so it always renders well.

We could eventually also enforce that garages always use 5 planes.

I'll have more UI/ergonomics questions later too.

KGJV wrote:QUOTE (KGJV @ Sep 9 2008, 04:06 PM) by "select mesh" would it be limited to a whole 'frame' as defined in the .X file or do you want a more dynamic selection that propagate along connected vertices?

Let's take your example picture in .X file format: it could have 6 frames (1 for blue thing , 1 for green inset and 1 for each red boxes). So selecting a frame and converting it to a HP is simple: remove the frame and place a HP at this position. So far so good for me.

But the same picture could be .X file with only 3 frames (1 for blue thing, 1 for green inset and 1 frame for all 4 red boxes). In that case selecting 3rd frame (the 4 red boxes) wouldn't work. So either the artist must go back in his 3D modeler to break the frame into 4 frames OR AMT2 could allow selection of connected vertices by clicking on one of the red boxes. Then only the vertices of this selected box would be removed and converted to a HP.

Is this worth the pain to code or are most 3D modeler outputs generally well structured enough (each logical mesh has it's own 'frame') ?

bolded is how i was thinknig it would be.
I think most things would have them as separate frames unless you went to extra effort to make them into one.

I say do it that way, and should people later say they need the selection of connected verts then that could be added later.
QUOTE So this would be the general tool to move thing around (and rotate too by adding extra 'grips').[/quote]
yes
QUOTE Is precise coords editing also needed (input boxes with the 3 coords) or do ppl never bother with numeric values?[/quote]
may as well, text boxes aren't hard to do, and precise control is handy some times, the text boxes could also display the current position of the currently selected object.
(could also display the current rotation, and allow for absolute or relative rotation to be input)

QUOTE hum this is not that simple because the input/output datas are 1 to 6 planes. I"m not sure we can always transform 1 to 6 planes into a box like the one you drawn. Original Alleg models use 5 planes so the 'box' would be 'closed' on one side (the bottom of the docking bay) and infinite toward its opening side.

This could work but I need 3D math experts for this /smile.gif" style="vertical-align:middle" emoid=":)" border="0" alt="smile.gif" /> I need the formulas, given 1 to 6 planes, to compute that 'box' as well its size ("cut the infinity") so it always renders well.

We could eventually also enforce that garages always use 5 planes.[/quote]
notice how the left most face is missing? (i made the lines around where it was thicker) - it's a 5 sided object

basically i'm saying, when placing the door, don't generate any planes until the export phase, just generate a box with a side missing for people to move and position, they then know that the missing side is where their door is (even though that's not strictly true, what is actually happening can be explained in a help file/tutorial).

so the user positions the box appropriately and changes it's shape.

when the file is exported to allegiance format, the faces of the box are converted to the planes and you know the inside faces of the box were the green sides of the planes.

when reading an allegiance .mdl, where three planes intersect (or where a plane intersects a line formed by two other planes touching - both describe the same place) you have a vert of the box, where planes intersect you have lines connecting the verts. since one of the faces is missing you won't know where to place the last 4 verts, so just place them a constant distance from the plane opposite to the one that is missing.

the user could click a face of the box and delete it to reduce the number of planes used

madpeople wrote:QUOTE (madpeople @ Sep 9 2008, 05:30 PM) when reading an allegiance .mdl, where three planes intersect (or where a plane intersects a line formed by two other planes touching - both describe the same place) you have a vert of the box, where planes intersect you have lines connecting the verts. since one of the faces is missing you won't know where to place the last 4 verts, so just place them a constant distance from the plane opposite to the one that is missing.

yeah "loading mdl" is my problem with this 'box' and my brain fried when I tried to do the 'plane intersections and other stuff' formulas (i guess i can do it but i'm tired these days /smile.gif" style="vertical-align:middle" emoid=":)" border="0" alt="smile.gif" /> ).

So if anyone can help, plz do :

input: 5 planes = 5 x (a position vector and a direction vector) = (P1,D1), ..., (P5,D5). (a vector is a (x,y,z) triplet).

output: the 'box' = the 4 verts (4x(x,y,z)) of 'bottom rectangle' and the direction (x,y,z) toward the 'open' side (which isn't always the normal of the bottom rectangle). With these I think i can draw something.

the winner get a cookie /tongue.gif" style="vertical-align:middle" emoid=":P" border="0" alt="tongue.gif" />


edit: actually output should be 4 directions instead of one (one direction for each vert of the bottom rectangle). if the planes really form a 'good box' then these 4 directions should be equal.

For positioning HP's, you had best include the "standard views" , ie top, right, front, and 3rd angle. The top, right, and front views should be orthographic projections of the wireframe, while the 3rd angle view can be perspective or trimetric.

oh, i forgot to mention, with moving, there should be "snap-to" options, suitable things to snap-to could be verts, edges or faces.

snapping to verts means wherever you move something, it will always move to a position of another vert.

snapping to edges means the new position will always be on the edge of a face.

snapping to a face means it will always be on a face.

face and edge options could be extended so that it snaps to the middle of faces or edges.

I'm hardly a math expert, but I'll give that a go:

For finding the verts, you need all the intersects of any three planes. An intersect point of three planes exists as long as
n1 . (n2 * n3) != 0
where
ni is the normal to the plane,
. is the dot product, and
* is the cross product.

To get all the verts, you'd need to check every combination of three planes from all the 4-6 planes you have as input.

For the box to be open, all of the verts you find will be in the same plane. This is the 'bottom rectangle' (or triangle, or...). You need a way to rule out all the planes that are not part of a vert. If you end up ruling out all of the planes, then the box is closed and you can just draw it between the verts. (The exception being if 4 or more planes intersect at a single point. But anyone who does that is asking for trouble.)

Once you know which plane is the bottom one, the cross product of the two open-sided planes at that intersect will give you the direction of the line that connects them. This is the 'direction towards the open side' iff the dot product of itself with the normal to the bottom plane is positive. If the dot product is negative, the open side is in the opposite direction.

The location of the intersects themselves can be determined from this equation.

I suspect you need at least 3 verts and therefore 4 planes for this to work.

Edit: Huh. I just noticed it's possible to have a six-plane open box arrangement with more than one bottom plane. Oh well. /doh.gif" style="vertical-align:middle" emoid=":doh:" border="0" alt="doh.gif" />

Whatever you do KG, make sure it uses generic and intuitive processes that can be standardized across modelling platforms. It would defeat the purpose to require formats for primitives, joints, etc. that are, say, Milkshape specific. Make whatever you do SIMPLE and platform independent.

As far as manipulating things in 3d space, I think the best way to do things is, for translation, use 3 arrows (like in mad's picture), you drag them different directions to move an object around, two circles (XY and XZ plane or something) to control something's orientation. Right click pick to select an object.