new DotScene loader

Discussion area about developing or extending OGRE, adding plugins for it or building applications on it. No newbie questions please, use the Help forum for that.
JeDi
Gnome
Posts: 351
Joined: Thu Oct 21, 2004 1:34 pm
Location: Diepenbeek, Belgium
x 3
Contact:

new DotScene loader

Post by JeDi »

Hi,

I wasn't really pleased with the DotScene loaders available now. DSI works, but is a bit too complex for its purpose imho, and is unmaintained at the moment. Nikki's loader works too, but is a bit too simple and lacking (no skybox support, no of nodes, ...). So I decided to write my own. I started with Nikki's loader, but there isn't much left of it. I also had a look at the DSI source code to handle quaternion parsing and such properly.

It isn't finished yet (putting in functionality as I need it at work), but I'll put it online somewhere if someone's interested. It handles about everything except cameras, terrain, billboards, planes, clipping, vertex and index buffers, externals, user data, and octree stuff. I don't think the wiki is the best place to put the code, cause it's quite long. A link in the wiki would be great though.

TODO:
- Add unimplemented functionality
- Convert to Ogre's code conventions (OK, not that important maybe, but I'm a neat guy)
- Provide loading progress information?
- Add a listening system of some sorts, especially for user data and such, and for overwriting the implemented creation functions (e.g. for creating nxOgre bodies instead of plain entities)


Here is the header and implementation.


Let me know!
Greetz,
JeDi
JeDi
Gnome
Posts: 351
Joined: Thu Oct 21, 2004 1:34 pm
Location: Diepenbeek, Belgium
x 3
Contact:

Post by JeDi »

So nobody has tried this yet, right? Well we are, and it is working great :lol:
Anyway, if someone uses this, I'll update the source now and then.

Greetz,
JeDi
User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
x 179
Contact:

Post by jacmoe »

I just had a quick look, and I like what I see. Basically, it is DSI turned into two files, with saving and versioning removed.

I would add saving asap, as well as support for userdata. :)

Please put it on the Wiki, right next to the two exsisting ones! :wink:
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
JeDi
Gnome
Posts: 351
Joined: Thu Oct 21, 2004 1:34 pm
Location: Diepenbeek, Belgium
x 3
Contact:

Post by JeDi »

I just discovered a lot of errors in the rotation parsing code. As I bluntly copied that from DSI, I guess the errors are there too.
- It uses if(XMLNode->Attribute("qx") != "") etc. Which gives true even when no qx attribute is present (fixed by removing the != "")
- The other modes than quaternion elements are plain wrong. It searches for anglex three times, constructs one Vector3 from it, and provides that to Quaternion::FromAxes, which expects a pointer to three axes, so this will crash.

I'm not sure how this is supposed to be used, but I guess the initial idea is this way (and that's how I implemented it now):
- qx, qy, qz, qw is used for quaternion elements
- axisX, axisY, axisZ and angle is used for angle-axis
- angleX, angleY and angleZ is used for euler angles (not sure here, so not implemented for the moment)

Are the people that wrote the dotScene.dtd still around? Cause I would want to implement this correctly... I suppose nobody had to deal with these problems since the exporters use the quaternion elements method.

Greetz,
JeDi

P.S. I'll update the online version of the files as soon as possible, and put them on the wiki too, but we're a bit busy at work now...
User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
x 179
Contact:

Post by jacmoe »

If you have any updates, I'd like to see them! :)

I am going to (soon-ish) tend the DotSceneInterface @ ogreaddons.
And I'd very much like to incorporate your improvements/bugfixing. :wink:

I am not allowed to upgrade the dtd, but you can ask pjcast to *consider* the proposed changes.
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Vectrex
Ogre Magi
Posts: 1266
Joined: Tue Aug 12, 2003 1:53 am
Location: Melbourne, Australia
x 1
Contact:

Post by Vectrex »

great. I really think the dotscene is worth maintaining and updating, to at least the level that oFusion supports. Saving is important I think too.
oFusion has the rather nice function of taking max animation and converting it to ogre keyframes
JeDi
Gnome
Posts: 351
Joined: Thu Oct 21, 2004 1:34 pm
Location: Diepenbeek, Belgium
x 3
Contact:

Post by JeDi »

I finaly got to wiki this: go here!

All comments appreciated. I hope this will be useful for someone...

Greetz,
JeDi
Ajare
Goblin
Posts: 282
Joined: Sat May 14, 2005 9:20 pm
x 1

Post by Ajare »

I will probably be moving over to DotSceneOctree soonish, so this is likely to be very useful. Thanks for doing this!
User avatar
funshark
Gnoblar
Posts: 13
Joined: Thu Dec 14, 2006 1:52 pm
Location: paris, FRANCE
Contact:

Post by funshark »

I'm trying to use your very useful new dotsceneloader and i have one question cause i have some errors with building :
What version of tinyXML are you using?
JeDi
Gnome
Posts: 351
Joined: Thu Oct 21, 2004 1:34 pm
Location: Diepenbeek, Belgium
x 3
Contact:

Post by JeDi »

Hi,

I have no idea what version it is, but I zipped the used files to http://lumumba.uhasselt.be/~jedi/files/tinyxml.zip

Greetz,
JeDi
User avatar
metaldev
Orc Shaman
Posts: 761
Joined: Thu Mar 17, 2005 11:56 pm
Location: Boston
x 15
Contact:

Post by metaldev »

Hi Jedi,

Thanks so much for this code!
I am also having trouble compiling it, though.

for each of the lines that declare:

Code: Select all

if(XMLNode->Attribute(attrib))
visual studio returns an error:

Code: Select all

error C2664: 'const char *TiXmlElement::Attribute(const char *) const' : cannot convert parameter 1 from 'const Ogre::String' to 'const char *'
        No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called
would it be possible to supply or suggest a fix for future users of the dotSceneLoader?

(your xml .zip link seems to be broken but either way it would be nice to be able to use it with the latest tinyXml and not bother you for your version in the future :P i am using 2.5.3)

thanks for any help!
JeDi
Gnome
Posts: 351
Joined: Thu Oct 21, 2004 1:34 pm
Location: Diepenbeek, Belgium
x 3
Contact:

Post by JeDi »

Hi,

The compile error you are having looks like it's easy to fix. My version of tinyxml probably had stl support, so I could throw Ogre Strings at it. Try adding ".c_str()" to the Strings that are given to tinyxml.

The server where my tinyxml version is hosted had a power failure, not sure when it'll be online again...

Good luck!

Greetz,
JeDi
User avatar
metaldev
Orc Shaman
Posts: 761
Joined: Thu Mar 17, 2005 11:56 pm
Location: Boston
x 15
Contact:

Post by metaldev »

it still errors :(

Code: Select all

dotSceneLoader.obj : error LNK2001: unresolved external symbol "public: class TiXmlElement const * __thiscall TiXmlNode::FirstChildElement(void)const " (?FirstChildElement@TiXmlNode@@QBEPBVTiXmlElement@@XZ)
dotSceneLoader.obj : error LNK2001: unresolved external symbol "public: class TiXmlElement const * __thiscall TiXmlNode::FirstChildElement(char const *)const " (?FirstChildElement@TiXmlNode@@QBEPBVTiXmlElement@@PBD@Z)
dotSceneLoader.obj : error LNK2001: unresolved external symbol "public: class TiXmlElement const * __thiscall TiXmlNode::NextSiblingElement(char const *)const " (?NextSiblingElement@TiXmlNode@@QBEPBVTiXmlElement@@PBD@Z)
dotSceneLoader.obj : error LNK2001: unresolved external symbol "public: __thiscall TiXmlDocument::TiXmlDocument(void)" (??0TiXmlDocument@@QAE@XZ)
dotSceneLoader.obj : error LNK2001: unresolved external symbol "public: char const * __thiscall TiXmlElement::Attribute(char const *)const " (?Attribute@TiXmlElement@@QBEPBDPBD@Z)
bin\Release\UIattempt.exe : fatal error LNK1120: 5 unresolved externals

is tinyBind what you used?
http://sourceforge.net/projects/tinybind/

ill test it out tonight
JeDi
Gnome
Posts: 351
Joined: Thu Oct 21, 2004 1:34 pm
Location: Diepenbeek, Belgium
x 3
Contact:

Post by JeDi »

It looks like tinyxml isn't linked with your library. The server is back online, so you could try this tinyxml. Just add the files to your project so they will be linked with it.

Greetz,
JeDi
User avatar
Evak
Orc Shaman
Posts: 707
Joined: Sun Apr 02, 2006 7:51 pm
Location: Sacramento, CA
x 1
Contact:

Post by Evak »

Theres a Ofusion .OSM serializer library coming out soon to compliment the Ofusion sceneloader library. We will be using it in FlowED to let you load multiple OSM's containing scene data like environments seperate gameplay objects etc and save out new scenes OSM scenes.

EDIT:

The OSM serializer saver library is out now for Ofusion Pro users.
Last edited by Evak on Sun Jun 24, 2007 9:30 pm, edited 2 times in total.
User avatar
metaldev
Orc Shaman
Posts: 761
Joined: Thu Mar 17, 2005 11:56 pm
Location: Boston
x 15
Contact:

Post by metaldev »

Jedi,

you were correct, being a noob at C++ i didnt know that it made a difference if you linked to a file than actually having it built in with your project.

So it compiles now (with the tinyXML from sourceforge).

The change to the code included adding .c_str() and making sure tinyXml source are listed in the same project.

it seems to use your code properly i will have to learn to use the ResourceGroupManager first which i will do next.

thanks for your help!
JeDi
Gnome
Posts: 351
Joined: Thu Oct 21, 2004 1:34 pm
Location: Diepenbeek, Belgium
x 3
Contact:

Post by JeDi »

Glad I could help. You can enable stl support with some flag in tinyxml by the way, so the .c_str() additions aren't necessary. But it works exactly the same.

Greetz,
JeDi
artheseus
Gnoblar
Posts: 5
Joined: Thu May 03, 2007 3:27 am

Post by artheseus »

Hi,

I was wondering if DotSceneLoader use the World Geometry features (like SetWorldGeometry, StaticGeometry, etc)

Artheseus

EDIT: Since the static attribute is not being used for anything, maybe it could indicate if the Entity should be add to a StaticGeometry object or not...
JeDi
Gnome
Posts: 351
Joined: Thu Oct 21, 2004 1:34 pm
Location: Diepenbeek, Belgium
x 3
Contact:

Post by JeDi »

Hi,

Using the static objects to create static geometry in Ogre is exactly what we do in some of our applications. But there are too many application-specific things to consider (what to do with the lights, whether or not to keep the original entities for ray queries, what to do with animated entities that are tagged static, ...) to write general code for handling this.

You can use the staticObjects list inside the loader though, to iterate over all objects that where tagged static. You can decide what to do with them.

Greetz,
JeDi
wolverine
Gnoblar
Posts: 11
Joined: Fri Jul 06, 2007 3:19 pm

Post by wolverine »

Dear Everyone!

I have sent the following e-mail to many of the ex-maintainers of dotsceneinterface and dotsceneviewer and Sinbad asked me to post it in the forums, so you can review my proposals on furhter developing the
two projects.
The mail was the following:

Dear Everyone,

I'am Balazs Hajdics from Hungary (a small country in central europe).

I writing to you because I would like to take over the maintaince of projects dotsceneformat and dotsceneoctree in ogreaddons.

It looks like for me that currently it is abandoned, no one has contributed to it for a while. Because I see no appropriate license companied with these projects I assume they are totally free without restrictions, so I could just simply further develop it for our own project, without commiting it back to the community, however I don't want to do this for many reasons.
First it wouldn't be a nice thing :-). I believe in open source, the sharing of knowledge, and its power. Especially when trying to stop some huge companies from becoming the only companies developing softwares (usually low-quality bugous softwares with humble and closed source code) and owning everything related to softwares..
The second is trivial and merely practical: if someone starts to further develop these "map formats" while we are working on them, it
could become really hard or impossible to merge the two different developing branches (which may differ totally in design too). This would make a headache since we may need the features in the new version.


Long time ago I have started to assemble a garage team. We have had many smaller and mainly "learner" projects in the past (during high-school and university). And at a stage when we have felt ourselves ready we started to develop a RPG game. Being a garage project we had to face many difficulties and we had a longer disruption of the development. However we stabilized almost all circumstances (e.g.most of our team members are now working in half-time jobs to ensure both living conditions and continuous development of our game) and by now we are working on our game for 7 months without disruption (we had an 1.5 year of development process earlier followed by a longer idle phase).

We have had our own self-developed 3D Engine (I was working on it for 1.5 years), but when I met Ogre it really amazed me. There were many reasons we did not come to the decision of using open source engines as our game engines before. However the main reason was the weak design (not taking into account even the most basic Object-Oriented phylosophies like flexibility, reusability, modularity or the ability to easily further develop the core code) and the real humble code of these engines. Of course Ogre was different. I rarely see work of that quality. So you guys own my and my teams appreciation. We decided to drop our current 3D engine and start using Ogre. It was a real hard decision that was made after taking a survey of Ogre. Of course not full survey (Ogre is so big and we have many other engines to write and integrate), we didn't have time for it, currently this is only a garage project anyway ;-):-)).



-------------------------------------------------------------------------------------------------------------------------------------------
Roadmap
-------
(elements are listed in the order of priority for our project)

- I would like to place the whole work under LGPL.
- Simplifing and integrating the two projects. Currently dotSceneInterface does not load world geometry, however it loads static entities as they are without any options to instruct it to ignore them. This is annoying since currently I have to unload static objects manually if I want to set the world geometry on the DotSceneOctreeSceneManager just after I have loaded the scene with DotSceneInterface. Similarly DotSceneOctreeManager loads lights and environment while loading the static world geometry (why? they aren't a classic static "world" geometry anyway). So again I have to remove them by hand, since DotSceneInterface has already loaded them by the time DotSceneOctreeManager gets called.
- Compiling dotsceneformat and dotsceneoctree with the lates stable release of Ogre.
- Finishing parsing of the current dotsceneformat specification. (e.g. element <particleSystem> is totally ignored, attribute "userDatareference" is ignored in all elements, attribute "materialFile" is ignored in element <entity>, attribute "clipping" is ignored in element <environment>, etc.)
- Finishing saving of the current dotsceneformat specification. (e.g. attributes "vertexBuffer" and "indexBuffer" is not saved with element <entity>
- Slightly extending dotsceneformat specification. E.g. adding attribute "texture" for lights. It would be really usefull, since our project is using cubic-textures (and in some rare cases volumetric textures) for lights to make arbitrary light shapes possible. It would be nice for Ogre to support setting these textures in Light objects and binding them to shader parameters in the materials. :-) There are many other needs for extension like adding "queryMask", "visibilityMask" attributes to entities.
- Providing some kind of listener interface(s) for user defined callbacks on loading specific objects (especially usefull for userDataReference).
- Pre-declare of resources for proper loadingtime forecast.


In the long term:
- Adding sub-project for pre-computing radiance transfer on scenes and storing PRT textures in octree nodes.
- A special static octree may be implemented instead of the currently used dynamic one. This will speed up visibility surface determination.
- Extending dotsceneformat and dotSceneLoader to be able to support many types of scene managers. E.g. element <BSP> would be added to the elements that can be contained by the element <scene>. Terrain scene manager support would be finished. dotSceneLoader would create the proper scene manager on the loading of the scene.
- Extending dotSceneInfo to provide more data, and maybe making it a non-static

-------------------------------------------------------------------------------------------------------------------------------------------
Currently our goal is just to simplify and integrate the two projects (or at least make them more compatible); parse more elements and attributes from the current dotsceneformat specification; save more elements and attributes to .scene files and extend the base dotsceneformat specification a while. These features cover the ones which are the most important for us now.

So in the short term (in the next few months) do not expect too much, only a few contributions would be made because currently our highest priority is the gameplay (due to the lack of human resources and the fact that we are developing a game). After a few contributions there will be a lots of months of inactivity of this project again. However in the long term (in the next 1.5-2 years) we are going to develop all the features mentioned in the roadmap and maybe even more.



And sorry for writting to you all and maybe disturbing you, but I weren't sure who I am supposed to write to (the web site mentions the current maintainers of the addon I wish to contribute to, or one of the Core members, however there were/are many maintainers and many core members ?).

And I also have to apologize for the long and boring intruduction but I think that in the long term me and my team (and hopefully in the future I will say "our company") will do a lot of contributions to either Ogre or to ogreaddons. So I was thought writing and reading an introduction as long as this wouldn't become a wasted time :-) ... at least not in the long term.



I wish you steadiness, lot of time, energy, proper circumstances and some luck for continuing the development of your great project!
Best regards,
Balázs Hajdics
Development director, Programmer, Game Designer
DFS Team
User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
x 179
Contact:

Post by jacmoe »

DotSceneOctree already is licensed under the LGPL.

DotSceneInterface is probably under a whatevar license, so you could relicense it.

The maintainer of DotSceneOctree is sharkyx, according to this forum post:
http://www.ogre3d.org/phpBB2/viewtopic. ... ceneoctree

Please contact him first regarding maintainer ship of that addon! :)

Nedelman, the maintainer of the OgreMax Scene Exporter made a really nice dotscene loader - you can get the code from downloading the OgreMax plugin - the source is in the loader example.
Looks a lot more up to date.


DotSceneOctree *is* updated to Eihort.

DotSceneInterface is probably not - been a while since I tested it.
Feel free to improve it.


However:

Changes to the official dotscene format should go through pjcast / Ogre Team.

Would be a good idea to be able to tell the dotsceneinterface loader to use an expanded DSI format.

Looking forward to hearing from you. :)
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
User avatar
oddrose
Orc
Posts: 470
Joined: Thu Feb 15, 2007 2:08 pm
Location: Gothenburg, Sweden
Contact:

Post by oddrose »

did the thing ever go under LGPL?
JeDi
Gnome
Posts: 351
Joined: Thu Oct 21, 2004 1:34 pm
Location: Diepenbeek, Belgium
x 3
Contact:

Post by JeDi »

I've updated the loader code. Still not completely implemented, but more complete than the last version. For the interested: wiki page.

Greetz,
JeDi
User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
x 179
Contact:

Post by jacmoe »

That generally sucks, JeDi.
Not because you posted your code, but because you didn't upgrade the DSI code from the addons.
Who needs yet another dotscene loader?
I mean: we have a lot of different dotscene loaders floating around - the OgreMax viewer dotscene loader from nedelman is probably the best of them.

Would be a lot better if you upgraded the DSI - having a loader in CVS is a lot easier to manage. :)


I am not against your loader, JeDi - but why not contribute to an existing loader?
I mean: does the wiki really need yet another loader?
It's got two or three already.
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
x 179
Contact:

Post by jacmoe »

Don't get me wrong. You know what I mean.

I actually asked about your dotscene loader - and praised it - when you posted the first draft a while ago. :wink:
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Post Reply