DeleD Community Edition

[jwatte]

With the release of 1.5 coming up, do you have any preview of the changes for plugins and/or file format?

[Paul-Jan]

DeleD 1.5 will not have any changes to the file format. We had originally planned to, but as our schedule doesn't allow us to actually implement any of the features that require this new format we have decided to drop it off the 1.5 list.

The new file format will store additional scene, viewport, material and light properties, and will be introduced in version 1.5x. The actual new functionality will be introduced over several sub-releases from there.

Of course, full backwards compatability with the old file format will be maintained.

Does that answer your question?

[jwatte]

Good enough.

May I re-iterate the suggestion that you add the ability to store arbitrary keyword/value pairs, both in the scene, and on each kind of object (node, material, etc)? This would help certain plug-ins a lot.

[Paul-Jan]

Yeah, you may definitely re-iterate that, thanks for pushing quality! To be honest, in the Torque exporter I already assume this is the way things will work, and that those key/value pairs are stored in what is currently known as the "Tag" property (and delimited by the vertical pipe symbol)...

Perhaps I'll even try to push some sort of 'entity' support (where an "entity" is a named set of predefined keys) into the file format, but I'm not sure yet. You will want the ability to store and retrieve the entity definition from some separate files, and that sounds like a bit of a hassle for now.

Besides primitives, additional objects that will have a 'tag' (i.e. collection of user properties) are Material, Material Layer, Light, and the Scene as a whole. I am not too sure what you mean by 'node', but if I missed anything in the above feel free to point that out.

[jwatte]

The problem with using "tag" is twofold:

1) The user would probably want to have a field where he can write in an arbitrary name/comment. This competes with the plug-ins.

2) Using pipe separated keyword/values means that pipe cannot be part of the keyword (or value).

There's also a third: Some plug-ins may decide not to preserve keyword/value pairs they don't know about, thus nuking the data from another plug-in.

[Daaark]

[jwatte]

[stumcd]

On the subject of "who'd use a pipe" the format should really allow any character or ban (in GUI)/convert (in loader/exporter) characters it can't handle.

For example you can use semi-colon in an object name and the .dmf wont load back in.

Likewise comma breaks Ryan Fleet's DMFLoader.c.

--STU!

[Daaark]

[jwatte]

[Paul-Jan]

jwatte: Thanks for the comments on the 'tag' v.s. properties implementation choice, you've got a point. Although I must say we haven't observed many artists using the 'tag' field for the purpose of storing comments this far, we'll take it into consideration. Historically the 'tag' was _meant_ for technical use, and a 'comment' field was left to be implemented at a later stage. Now might be the time.

I don't agree on the 'pipe character is not suitable as a delimiter' argument. Same holds for any other character in the keyboard range, so we'll have to implement either blocking or escaping anyway.

Valid point on the 'plugins overriding eachother's properties' thing, but I don't see a decent solution to this issue without making things horribly complex really quick. Some properties you might want to share with any plugin, other properties might be private to your own, and some you might only want to share with certain subsets of plugins. Eventually the file format might need to be adapted for these things, but at this moment advanced collaboration between plugins is not a pressing issue.

Ah, and on a less serious note, I think having the plugin pass it's own name as an argument in those API calls is a big no no, the API should implicitly provide for that

stumcd: Thanks for reporting the semi-colon issue! We'll either ban it from the user-interface or escape it in the new file format (or both).

[CMe]

[jwatte]

Passing the plug-in name is actually a good thing, because it allows plug-ins to share settings if they want. Whoever came up with the setting first, everyone else who wants to use that particular setting will pass their name in.

An alternative is to use a single name, and just use a colon to separate "namespace" from "name". "nuxporter:output_path" is not much worse than "nuxporter","output_path".

[CMe]

Regarding delimiters and such. Have you considered switching the file format to something more meta structured? Something like bencoding comes to mind.
_________________
drop into #delgine on irc.scene.org

[Paul-Jan]

jwatte: Your 'namespace' suggestion for plugin properties does require that plugins need to be explicitly aware of each other's names before they can share settings. How do you propose to handle this? Or would shared properties not be prefixed by a name at all?

CMe: Once in a while we re-evaluate whether it would pay off to move on to another file format: we discussed most options from XML to chunk-based binary. So far we don't think moving to a new file format structure would justify the effort, but we keep our options open for the future.

Suggestions are welcome of course (thanks for suggesting bencoding, never seriously looked at it before!), it is just not a very pressing issue atm. If we had to choose, I think we'd sooner abstract the file format from the plugins by providing a structured plugin api than invest in creating the 'ultimate' file format. Of course, given enough time and other resources, 'both' might be nice

Thx for updating the code template, I'll put it online in a second!