Delgine 3D Tools & Content DeleD Community Edition
Forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

1.5 Plugin API
Goto page 1, 2  Next
 
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies.    DeleD Community Edition Forum Index -> DeleD Plugins
View previous topic :: View next topic  
Author Message
jwatte
DeleD PRO user


Joined: 26 Apr 2006
Posts: 513

PostPosted: Wed Aug 02, 2006 9:59 pm    Post subject: 1.5 Plugin API Reply with quote

With the release of 1.5 coming up, do you have any preview of the changes for plugins and/or file format?
Back to top
View user's profile Send private message
Paul-Jan
Site Admin


Joined: 08 Aug 2004
Posts: 3066
Location: Lage Zwaluwe

PostPosted: Thu Aug 03, 2006 2:59 pm    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message Visit poster's website
jwatte
DeleD PRO user


Joined: 26 Apr 2006
Posts: 513

PostPosted: Thu Aug 03, 2006 9:00 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Paul-Jan
Site Admin


Joined: 08 Aug 2004
Posts: 3066
Location: Lage Zwaluwe

PostPosted: Fri Aug 04, 2006 7:45 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message Visit poster's website
jwatte
DeleD PRO user


Joined: 26 Apr 2006
Posts: 513

PostPosted: Fri Aug 04, 2006 8:43 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Daaark
DeleD PRO user


Joined: 01 Sep 2004
Posts: 2696
Location: Ottawa, Canada

PostPosted: Fri Aug 04, 2006 9:59 pm    Post subject: Reply with quote

Quote:
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.
???

Quote:
2) Using pipe separated keyword/values means that pipe cannot be part of the keyword (or value).
Who would use a pipe? It's the least used symbol of all the ones on the keyboard, even coming after the ones where you hit ALT and type a number.

Quote:
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.
Then the plugin has a bug. This is no different from nuking the geometry.
_________________
Back to top
View user's profile Send private message Send e-mail Visit poster's website MSN Messenger
jwatte
DeleD PRO user


Joined: 26 Apr 2006
Posts: 513

PostPosted: Sat Aug 05, 2006 3:23 pm    Post subject: Reply with quote

Quote:
???


Many artists want to make notes about nodes. They'd use the "tag" field for that (because there's no "note" field).

Quote:
Who would use a pipe?


My artists.

Quote:
bug in the plug-in


An API that requires less precision of the plug-in writer leads to fewer bugs.
Back to top
View user's profile Send private message
stumcd
Member


Joined: 02 Jul 2006
Posts: 37
Location: Edinburgh - Scotland

PostPosted: Sat Aug 05, 2006 6:44 pm    Post subject: Reply with quote

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!
Back to top
View user's profile Send private message
Daaark
DeleD PRO user


Joined: 01 Sep 2004
Posts: 2696
Location: Ottawa, Canada

PostPosted: Sat Aug 05, 2006 7:38 pm    Post subject: Reply with quote

jwatte wrote:
An API that requires less precision of the plug-in writer leads to fewer bugs.
What are you talking about? It's not hard to append any new data onto the end of the string that is already there, or just copy it directly over.
_________________
Back to top
View user's profile Send private message Send e-mail Visit poster's website MSN Messenger
jwatte
DeleD PRO user


Joined: 26 Apr 2006
Posts: 513

PostPosted: Sun Aug 06, 2006 4:40 am    Post subject: Reply with quote

Quote:
What are you talking about? It's not hard to append any new data onto the end of the string that is already there, or just copy it directly over.


And then another plug-in does the same thing, and when you want to update your settings, you have to remove your own settings (which may be wherever inside the tag), without removing anyone else's settings, and then append your own settings to the end.

Yes, it's doable, but it's just tricky enough that some plug-ins may not test all the cases (especially since you might not even have all other plug-ins to test with). Thus, the overall experience for the user is likely to be diminished. I've designed several plug-in APIs for applications and even OS-es before. I know that the biggest mistake you can make is to require perfect cooperation between plug-ins. I'm trying to impart this wisdom to DeleD, which I think is a pretty cool app that deserves my support. (Notice my total absense from the Blender forums, for comparision :-)

What's so wrong about this API?
Code:
void SetTag(ObjectId object, String pluginName, String tagName, String tagValue);
String GetTag(ObjectId object, String pluginName, String tagName);
void RemoveTag(ObjectId object, String pluginName, String tagName);


(let's assume there's some kind of ObjectId -- I don't know if it's a string, an int, or something else)

It would be easy to implement (a map of tags for each object), and it totally isolates plug-ins, unless they explicitly go looking for data from another plug-in.
Back to top
View user's profile Send private message
Paul-Jan
Site Admin


Joined: 08 Aug 2004
Posts: 3066
Location: Lage Zwaluwe

PostPosted: Sun Aug 06, 2006 8:08 pm    Post subject: Reply with quote

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 Very Happy

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).
Back to top
View user's profile Send private message Visit poster's website
CMe
Member


Joined: 30 Jun 2005
Posts: 72
Location: Ontario Canada

PostPosted: Sun Aug 06, 2006 9:41 pm    Post subject: Reply with quote

stumcd wrote:

Likewise comma breaks Ryan Fleet's DMFLoader.c.


Ah thats true! I can remedy that. However using a semi-colon in the tag property will cause curruption in the dmf file itself. DeleD won't be able to reload the file. I guess this last part should be placed in the bug forum. That I can't do anything about.

EDIT: updated code with fix for the comma issue + other fixes. I've now wrapped this up with a VC2005 template for writing plugins. Just a warning for anyone using the CDMFLoader code. There are a lot of changes in comparison to the files hosted here on the DeleD site which breaks compatibility.

http://rmfx.50webs.com/plugin_template.zip
_________________
drop into #delgine on irc.scene.org
Back to top
View user's profile Send private message Visit poster's website MSN Messenger
jwatte
DeleD PRO user


Joined: 26 Apr 2006
Posts: 513

PostPosted: Mon Aug 07, 2006 2:22 am    Post subject: Reply with quote

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".
Back to top
View user's profile Send private message
CMe
Member


Joined: 30 Jun 2005
Posts: 72
Location: Ontario Canada

PostPosted: Mon Aug 07, 2006 4:57 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message Visit poster's website MSN Messenger
Paul-Jan
Site Admin


Joined: 08 Aug 2004
Posts: 3066
Location: Lage Zwaluwe

PostPosted: Mon Aug 07, 2006 7:02 pm    Post subject: Reply with quote

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 Smile

Thx for updating the code template, I'll put it online in a second!
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies.    DeleD Community Edition Forum Index -> DeleD Plugins All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum