DeleD Community Edition

[Twixn]

Hey all,

I work with large (and getting larger ) levels
that include alot of meta data stored as objects
(EG, like an NPC, which i use a simple box
for placing them).

The problem here is that i have to spend ages
going through my object list, selecting objects i
want to affect the light mapping.

Would it be possible to actually add a perminant flag
into the object for whether it should affect the lightmaps?

Or perhaps a new type of object, which doesnt affect the
lightmap. like an 'Actor' object. one used specifically for
external objects like powerups, NPCs etc.

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

[Jeroen]

Yes, a very interesting idea, which has played a role in our minds sometime in the past. What do you have in mind exactly? Something like the current light objects? Some simple, not-mutatable, 3D object that you can place in your scene having 1 or more Tag-like properties? Or something more advanced? Tell us!

[Twixn]

For flexability (as opposed to making you design an object that
fits my needs exactly, but more than half of it would be useless to
anyone else) i think something along the lines of the light object.

Honestly, all i really need is an object with a name and a user tag.
Anything else just makes my code and map more graceful.

Although, perhaps (seeing as this object would rely on user data)
a more complicated user data system is needed....like a list of
'variables' with 2 values each (name and value), im not sure how
you impliment this in the GUI but perhaps in the file the data can
be stored like so:

...
numVariables;
variableName;value;
variableName;value;
variableName;value;
variableName;value;
...

EG:

3;
Type;NPC;
Name;Bob;
Health;100;

etc.

Essentially its just a variable list of 'variables' with 2 values
each, name and value.

This would be very usefull for adding objects like NPCs, pickups,
events (like triggers, perhaps even with scripts), modifying
external objects (like making a 'door' actor, than links to a normal
object, signallying that that normal object is a door), etc etc.

Tell me what you think anyway.

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

[Paul-Jan]

Like Jeroen said, we have been giving this topic some thought already. More specifically, you have been addressing two different issues here, already on our list.

1. Materials will get additional properties whether or not they (a) affect the lightmap and (b) are affected by the lightmap. To solve your particular case, you would just assign such a material on your objects. This is a change that has been planned for quite a long time now, and will be implemented as soon as we introduce the next fileformat. Which is really really soon.

2. Object user data needs to be made accessible in a more structured way than through a simple 'tag string'. We haven't yet completely decided on how this would be best implemented exactly, so feedback like you just provided is most welcome!

[Twixn]

Ok, well im interested to see how both of those issues pan out.
Im glad to hear that something simillar to what i originally wanted
(a flag for lightmapping) is already under way (even if its just
discussion atm).

Have you had any thoughts on an 'Actor' object? Pretty much
user data with a position? I thought it would be a useful object
for people like me (engine/game designers using DeleD).

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

[Paul-Jan]

Yeah, I remember discussing exactly that quite some time ago. It's good you bring these things up. I really like the name Actor by the way, back then people suggested the name Entity (some other editors apparently use that name for a very similar concept), which I personally dislike because it already is reserved for a different technical concept and too broad (everything is an 'entity' in some way). But Actor is nice (at least, in my opinion)!

Some of the issues when implementing such a thing is:
- how to visualize it within the editor? Like a little man, or just a cube, or what?
- Would it only have a position, or an orientation too? (besides the user-definied properties, that is)

As a sidenote, the reason why this didn't get a higher priority back then is that we reasoned you have to write application-specific code to handle the 'actors' anyway, so why not simply use any other primitive and filter the geometry of any shape marked 'actor' out? Perhaps you can tell us your side of the story, i.e. why would it be more convenient if things worked this way?

[Twixn]

I also had a problem thinking of a good name. I originally thought
of 'reference object', but it sounded weird

That is pretty much what i do now: I use a box roughly the
size of the final object's bounding volume with the name
"RHActor" ('RH' being 'ReHashed'). and some other data
in the user tag, like type, Angle, etc etc.

It works fine, the trouble is that its tedious and time consuming,
not to mention ungraceful. The prime problems i have are
light mapping and level testing. And identification, which will get
worse once i start adding path finding nodes and script driven
events to my levels.

The other problem is physics/collision... which is another 'grace'
issue. As the entire level has to be checked to see which
objects are static parts of the level, or actors.

With visualization, i had 2 thoughts...one was that the object itself
could be an 'A' model for actor...or perhaps exactly like the light
object, relying heavily on my second thought which is colour: As in
the actor in DeleD has a 'type' colour...primarily to easily distinguish
between different types of actors, such as NPC's, pickups and path finding
nodes etc.

I think both position and orientation is a good idea, i think the main
question is will the orientation will be used more often than its not?
At the moment i only use YAngle for NPC's and pickups mostly, as the
NPCs are always upright, and pickups are always on the ground.

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

[Daaark]

Maybe a plugin/program where you can zoom around your level and drop entities around it, and then save out a seperate file that is alist of these things? IMO, that is the best option. Define your own entities in a file, then drop from a preset list in the new program.
_________________

[Twixn]

Thats an idea.

It could avoid some bloat in the file format (and it wouldn't
force a new file format version number either).

Its something i'll have to look into.

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