DeleD Community Edition

[Sweenie]

Hi.

Not sure wether this has been requested before or if it already can be done, but it would be great if DelED supported some kind of marker/node/entity.
By this I mean some kind of "Dummy" object that can contain custom info. This object could then be identified by the game as spawnpoints, triggerzones and so on.
The ideal would be if it looked somewhat like the Directional Light object so that it would be easy to determine it's orientation.

I know I could create a cube and make use of the Tag for this, but it can be troublesome to determine orientation with a cube and that would also add not wanted geometry to the scene.

Even better would be custom markers defined by a configfile or something like that.

Perhaps something like this...
CUSTOMMARKER
{
Name="PlayerSpawn"
Gizmo="Directional"
}

CUSTOMMARKER
{
Name="BoxTrigger"
Gizmo="AlignedBox"
}

You get the idea...
Feel free to comment this.

[Paul-Jan]

This has been requested before, but no decisions have been made on final implementation yet, so a specific request like yours is most helpful!

We are currently leaning towards implementing those dummy objects as a separate primitive type (meaning it will be stored inside the DMF like any other primitive). Perhaps even with a configurable 'gizmo' (any DeleD prefab) like you suggest here. We will make the DeleD concept of user properties more powerful anyway, so we've got that covered.

Whatever the actual implementation, we still need a good name. "entity" is popular, but already reserved for another purpose. "marker" could be nice, as it suggests a non-physical item.

An important aspect that should not be overlooked is the question "how do you get this information in your final rendering implementation"? None of the file formats we currently support for export supports these dummy items. You could load .DMF's into your engine, but as DMF is our internal file format it is not particularly geared towards end-user applications. May I ask your thoughts on your topic? Did you have plans to roll your own file format and write a custom exporter for it?

[Sweenie]

Well, I have thought of different solutions to this...

1. Creating a custom file-format that supports these "Dummies".
* Could be a heavy task and not very useful for others.

2. Create an .FBX exporter and use KFbxGenericNode combined with KFbxUserProperties for the Dummy objects.
* Still only useful for people that can make use of the .FBX format.

3. Create a custom exporter that only export these DummyObjects into some kind of XML-file.
* Useful for everone, though the leveldata will be at least two separate files(not a big problem though and in many cases quite practical)

4. Import the .dmf file directly into the engine.
* Might require some heavy coding.

I would probably go for nr 3 and I will also give nr 4 a shot by trying to create a dmf importer for the XNA Content Pipeline when it's out.

[Sweenie]

I just wonder, can the .dmf file be parsed the same way as you do with plugins?
By that I mean, does the dmf structure in memory have exactly the same structure as the written .dmf file?

[jwatte]

DMF is very similar to the plugin format, from what I can tell.

I like the name "marker" although "dummie" is good too. Right now, I use geometry with a special material name for this purpose, which is a reasonable work-around. Being able to parent markers to geometry would be useful, however.

[Daaark]

Why not a discussion on what you would use it for and then a realistic implementation can be born from it. (oops double post)
_________________

[Daaark]

Why not a discussion on what you would use it for and then a realistic implementation can be born from it. TO me it seems simple to implement, but just a question of making sure not to miss any obvious requirements the first time around.
_________________

[Sweenie]

Well, It should be generic enough so that everyone can make use of it.

I can list a couple of things which I would find useful and then maybe others can fill in?

I'm gonna start with the simplest one and then add to it...

1. Marker without orientation.
- Useful to mark out specific keypositions in the level that could be a spawnpoint for a multiplayer fps or any other dynamic object.

2. Marker with orientation.
- Same as above but can also inform the engine which direction a spawned player/object should face.

3. Marker with orientation & boundingsphere
- This one also adds a boundsphere that define a volume around the marker. Useful for triggerzones, gravityfields and such.

4. Marker with orientation & boundingbox(oriented or aligned?)
- Same as nr 3 but instead with a box volume.

Maybe all of the above could be one single marker there you toggle it's behaviour/appearance with the object inspector window.

All the markers should be able to handle an undefined amount of userproperties/tags.
Preferably a keyvalue-pair.
Possible values:
Strings, Integers, Floats, Colors(with a picker?)

[Paul-Jan]

Those properties make sense to me. The only thing I am not completely supportive of is adding property "type metadata" (string/float/integer/color/etc) in the first implementation, current plans where to keep everything free string data in the property key/value pairs.

If we are going to structure some of the data (orientation, bounding volume), I think 'marker' makes for a better name than 'dummy' (to me, a 'dummy' suggests there is no structured information at all). Other suggestions:
- 'token'
- 'location'
- 'point'
- 'item'
- 'notch'
- 'indicator'

[jwatte]

"marker" is good.

In fact, it would be good enough to be able to take any of the existing basic shapes, and mark them as being "markers" -- then you get the box, sphere, etc part for free.

A marker should probably not accept a material, and should render in a light-weight way (maybe similar to lights), and should not participate in lightmapping.

Most important, markers should be parentable to other geometry, so that if the geometry is moved, the marker is automatically moved with it.

Currently, I do Markers using geometry with a special material, but excluding them from lightmapping is lots of work, and they don't move with the geometry.

Usage includes showing where to place a particle system, where to place an interactable entity, and where to place player spawns. (In short, using this to make DeleD a poor man's level editor, as opposed to just geometry editor)

[Daaark]

Something that was used in Embrace/QERadient was a marker for a swinging door. You had to attach it to the door by making it it's parent, or attached object or whatever, and then where you put the point became the point the door woudl swivel around.
_________________

[Twixn]

Personally for the name, i prefer 'Actor'. As i will most likely be using this
type to place things like NPCs, PathNodes, weapons/pickups, and then things
like events (Ie, script triggers).

I like the idea of property+value for storing data about the 'node' (another name
to add to the suggestion list). It could be useful for data like orientation, size,
type etc. Although i agree with Sweenie's suggestions, but if not all can be done
suggestion 1 is more than enough.

-Twixn-
_________________
Failure is not an option!....It comes bundled with the software.