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.
Yeah, I understand what you're saying. We are probably going to switch to the ogremax loader too, I guess it is a lot more complete than this one.
But this isn't a new loader. I put this on the wiki a long time ago, long before ogremax. I just updated it to our current code for the few people that may be using it
Maybe we should add some more info about ogremax in the dotscene page of the wiki. We should point all newcomers to the most complete loader of the moment, which seems to be the one from ogremax. Although I haven't tried it yet...
anyone that help's me please. i'm desperade. i can't compile DotSceneLoader .cpp file in my project.
i'm using VS2005 with SP1 in Windows XP and it exists one piece of code that not compiles.
// Process userDataReference (?)
pElement = XMLNode->FirstChildElement("userDataReference");
if(pElement)
processUserDataReference(pElement, pEntity);
}
When i try compile the file give's me the next errors:
------ Build started: Project: lost, Configuration: Release Win32 ------
Compiling...
DotSceneLoader.cpp
.\DotSceneLoader\DotSceneLoader.cpp(741) : error C2065: 'pEntity' : undeclared identifier
.\DotSceneLoader\DotSceneLoader.cpp(742) : error C2227: left of '->setCastShadows' must point to class/struct/union/generic type
type is ''unknown-type''
.\DotSceneLoader\DotSceneLoader.cpp(746) : error C2227: left of '->setMaterialName' must point to class/struct/union/generic type
type is ''unknown-type''
Build log was saved at "file://d:\svn\lost0.2.6\lost1\Release\BuildLog.htm"
lost - 3 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
it's very strange this errors i know !!!!!!!!!, but i have others projects that use the Ogre::Entity object and works perfectly
the object is declared and instanciate perfectly, i think...
// Create the entity
Entity *pEntity = 0;
try
{
(...)
}
this errors is very, very, very , very strange and i don't know how solve this. and i do not make any ideia what is the problem
Weird... Hmmm, perhaps do a full Clean and Rebuild?
Or maybe try whittling down the try {} catch {} to nothing and see if it compiles? If it does, then add functions one at a time (compiling each time) to see perhaps something else is causing the compile error?
i find and the option "enable C++ exception" has the value Yes (/EHsc), and it works. i do not modified nothing and the file compiles knows. (i don't understend). my Visual Studio it must be crazy
I have written an e-mail to Steven yesterday, and he seriously recommended posting it in the forums too. Before posting the e-mail I would like to post an excerpt from one of our previous e-mails:
The reason I haven't submited any patches is that I have given up my original intentions to make the original 0.2.0 dotscene specification and its original parser/serializer with its original architecture working. Instead I have started to implement the new specification 1.0.0 and a parser/serializer for it, with extensible, plug-in oriented architecture, with the possibility to use listeners.
The rationale behind this can be found in the attached changelog.txt.
Many files were renamed or removed and many new ones were added.
I hope the new projects will satisfy everyone.
I think it would be wise to only submit a whole new bunch of projects according to dotscene loading/serializing/dotsceneoctree either when the parser is totally ready, or when the whole project is totally ready (including parsing, serializing, and extending the dotSceneOctreeManager (using StaticGeometrys instead of pure renderables, etc.)).
And now the e-mail I have written yesterday:
Dear Steven,
I just would like to notify you about the current state of development of the dotsceneformat/dotsceneoctree project. Its been a while since I have last written a mail.
The parsing part of the dotSceneInterface project is almost totally finished. Taking into consideration what you have written in your last mail I'm going to release a beta source code and also a binary demo package soon.
Main todo list until the first release includes:
- Some structural reorganization of the projects. Making one solution for all of the projects instead of the current "many projects, many solutions" format, making it compile both in my environment and with my path settings and with the path settings of the ogreaddon module of the Ogre cvs repository.
- Some further development for our XmlNodeProcessor class must be done.
- There are some unfinished element parsers: animation element parsers are halfly implemented and plane, curvedplane, etc. element parsers are not implemented at all (maybe they are not going to take place in the first release).
- Using/redesigning progress makers, progress listeners, reimplementing dotSceneInfo in a more structurated and object-oriented way.
- Cleaning dotsceneoctree project from dotSceneFormat parsing (the last maintainer started to reimplement the whole dotsceneloader functionality, while dotSceneOctreeSceneManager should only parse the world geometry part).
- Redesigning dotsceneconverter into a more object-oriented approach.
- Integrating dotsceneoctree, dotsceneconverter with the rest of the project.
The todos relating to dotsceneoctree might be ignored in the first release (it depends on my time).
I think the release date of the first package will be 21st or 23th of September, but it is possible that I'm going to delay it with one or two more weaks.
Although even the first release of the dotsceneloader is going to happen much more later than I have originally planned, it has much more functionality than what I have originally planned.
The first release will be a good oportunity for the community to get familiarized with it, to take survey of it and start using it. I have taken survey many projects giving support for .scene file format, but all of them implemented their own parsers (I'm not suprised, the original one was really bugous and unfinished). I would like things to be different with the new dotsceneinterface. I would like Yake, Blender, OgreStudio, 3dsceneexporter, etc. to use the ogreaddon .scene interface instead of reimplementing it, and I'm trying to make a work with a quality that makes it worth for using it.
Although I'm going to make the first release I fear, that it won't be in its final file structure, since there is no serialization or modification for the dotsceneoctree project. It is possible that files and directories are going to be added/renamed after the first release. I have used SVN and Team Foundation Server as a version control system so far, I can say that I'm an expert in subversion, even in its subtle things like writing hook script, or setting up, configuring and administrating a server. However I don't know CVS very well (I can say that I don't know it at all), so there are two possible ways, either I'm going to learn cvs which I don't have to much motivation for, since as long as I know it is really out-dated version control system in functionality; or someone else is going to make the commits for me. As long as I know CVS doesn't support file and directory renaming in the repository (while svn does), so I'm not sure about commiting the first release with the unfinished file/directory structure would be a good idea, but I may be wrong, as I said I don't know CVS very well.
The next step after 21st or 23th of September will be one of the followings:
- Hold the development of the project temporary (so I can return to the development of our game) and continue it at the beginning of 2008.
- Implement the serialization part.
The modifications/redesign/further development of the dotsceneoctree project and its scene manager is going to be started at the beginning of 2008. This is almost totally sure, since we have an internal milestone to our game at the middle of December..
The new dotSceneLoader is really feature reach, extensible, modular, heavily object-oriented, heavily tested (for almost all cases) and it has a really verbose error reporting system.
I have attached the new pre-specification dotscene.dtd to this mail, so you can take a look at what the new loader knows. Xml elements according to animations, animation states, tracks, etc. are unfinished and under heavy modifications, xml elements "plane" and "octree" are currently not parsed.
<!-- These elements have been removed see the changelog.txt for more information.
<!ELEMENT vertexBuffer EMPTY>
<!ATTLIST vertexBuffer
usage (static | dynamic | writeOnly | staticWriteOnly | dynamicWriteOnly | dynamicWriteOnlyDiscardable) "staticWriteOnly"
useShadow (true | false) "false"
>
An excerpt from one of my previous post: I think the release date of the first package will be 21st or 23th of September, but it is possible that I'm going to delay it with one or two more weaks.
Although even the first release of the dotsceneloader is going to happen much more later than I have originally planned, it has much more functionality than what I have originally planned.
As I have feared from it before, because of tasks relating to our game development I have to delay the first release of the new dotSceneLoader with two more weaks. Actually one weak would be enough, but this time I want the new deadline to be sure. So the new and final deadline for the first release (alpha) will be the 5th of October. At this time I'm going to release a binary package too, to make more people able to see what the new dotSceneLoader is capable of.
The reason of the delay is that I had to return to the programming of our project's material system and its shaders asap, because they have required some further developing/fixing in order to keep it up-to-date with the artists.
5th of October. It is final. The first release with the features I have previously mentioned in one of my post.
Good work on this - I think there's a good chance DotScene could be useful in my project. Maybe you can tell me how easy it is to extend DotScene with new geometry types? I represent my worlds as volumes, and have written VolumeManager, VolumeSerialiser, etc. Can I extend DotScene to include these new types?
You can easily extend the new dotSceneLoader, it is really modular (even the first release will be really modular, which doesn't support .dtd parsing).
It was one of the main design concepts of the new dotSceneLoader to take it easily extendable, without modifing or understanding the core code.
You just simple have to inherit a class from XmlNodeProcessor and implement the method parseElementImpl (and optionally parseElementEndImpl), and then register the new xml node processor with the dotSceneNodeProcessorTreeBuilder class.
We've just released a new version of the LEXIExporter, which exports .scene files according to the old DTD. I agree that the current .scene format isn't capable of representing the data needed in a scene, and I think the proposed DTD looks promising, but I also think it's off in some parts. The format should , in my opinion, avoid the direct coupling between nodes and animations. The animation data should be represented as the .mesh / .skeleton structure. This we have done with the latest LEXIExporter (1.0., which writes the animation data to a seperate file.
Why not have an optional trackTarget or lookTarget on the light type? A spot light is most likely to be oriented at a specific point, which we again could move around.
It's good to see the .scene format is kept alive. Cheers,
/Sethos
One problem in my game. when i load my terrain for the first time, no problems, the map loads perfectly, but when i leave the map and return to the menu and i try load again the map for a second time, an exception is launched to the screen.
it say's that Resource with the name flaxMesh already exists. in ResourceManager::add at d:\ogrenew\ogremain\src\ogreresourcemanager.cpp (line 113)
the entity's of my map are already in resourcesManager. but the problem is that for i load the map for the second time, the scene.scene file is opened with
String data = pStream->getAsString();
// Open the .scene File
XMLDoc = new TiXmlDocument();
XMLDoc->Parse( data.c_str() );
pStream->close();
pStream.setNull();
if( XMLDoc->Error() )
{
//We'll just log, and continue on gracefully
this->log->logMessage("[DotSceneLoader] The TiXmlDocument reported an error");
delete XMLDoc;
return;
}
}
catch(...)
{
//We'll just log, and continue on gracefully
this->log->logMessage("[DotSceneLoader] Error creating TiXmlDocument");
delete XMLDoc;
return;
}
// figure out where to attach any nodes we create
mAttachNode = pAttachNode;
if(!mAttachNode)
mAttachNode = mSceneMgr->getRootSceneNode();
this->log->logMessage(SceneName + " válido e aberto com sucesso ...");
this->log->logMessage("\n####################### processScene #######################\n");
// Process the scene
processScene(XMLRoot);
this->log->logMessage("\n####################### processScene end #######################");
// Close the XML File
delete XMLDoc;
ResourceGroupManager::getSingleton().clearResourceGroup(groupName);
this->log->logMessage("\n############################ PARSEDOTSCENE() END ############################");
These line are a reply to a previous comment from Sethos (one of the authors of LEXIExporter):
However the current .scene supports combining nodes and their animations, it is really modular. You can create one .scene file with only the animations and another one with the scene itself.
Saving animations only in the .mesh file is not a good idea. One of my main purpose with dotSceneLoader/Serizalizer is to be able to save the contents of every kind of Ogre SceneManager anytime during a gameplay, and then reload it later.
Node animations or pose animations created during gameplay (e.g. by scripts or a speach system) can be serialized and loaded into a .scene file without any problem. This and design fundamentals like that will gives us the ability to save our game at any time in any state, without having to care about what we have created after the last loading.
The current .dtd is not final, many extensions will take place and some modifications too (e.g. user of the dotscene format must be able to specify materials for each sub-entity of an entity, not only for the whole entiy). Making a spot light able to track something (or to look at something) will be put into the todo list.
Maybe a bit off topic, but is there a checking mechanism for these types of xml files? We are a bit in the same situation, we have an xml format that can be extended by plugins (so the plugins can define new tags inside a 'core' tag with the plugin type as parameter, the plugin is responsible for the parsing and writing of that part). We always used DTD in the past, but it seems it doesn't support including other DTDs at runtime.
Come to think of it, the DTD could be generated procedurally, using the plugins to add their specific parts to it.
Anyway, does anyone know a better way of handling this? And will there be some kind of scheme for the new dotScene format?
Here is the last letter I have sent to Steven, it contains information about the first release of the new dotScene related projects:
Dear Steven,
As I have promised I'm making the first release of the new dotScene projects. Today is the 5th of October, the date I have mentioned in the Ogre forums as the deadline of the first release.
Despite all of my efforts I were unable to get ready with everything I wanted to. Nevermind this is the first, initial release, there are many mores coming soon. DotSceneOctree and its converter is currently not integrated into the new DotSceneInterface. DotSceneProcessor does not parse octrees. The converter can't even be compiled. I have started their structural modifications and their integration to DotSceneInterface and I have also cleaned some of their sources, but it is really in an early state.
For almost all of the changes that have happened since the old (v0.2.0) dotScene projects please see changelog.txt.
For information about the developing indended to be done please see Roadmap.txt. It contains almost all the features which are going to developed at the upcoming 1-1.5 year. It takes so much time because (as I mentioned before) I also have a game to look after.
Please read the Readme.txt file before trying to install, compile or run any of the dotScene related projects. Reading section "dotSceneViewer.exe Documentation/Running in fullscreen mode" is especially important when you try to run dotSceneViewer.exe. Of course
section "Installation" also can't be ignored. Readme.txt also contains some usefull information about the projects and their development.
We have previously talked about my unfamiliarity with cvs. Unfortunatelly I haven't had the time to take a survey of it, so I'm releasing a snapshot of the code.
I'm also sending a binary release (contents of the media sub-directory also consists the .exe and the .dll not only the media) in case anyone wishes to try it out, without having to care about the (probably difficult) process of compiling. I am sending the package as an attachment to this mail. I have also uploaded it through the patch submit system of sourceforge. I don't know which one you prefer and I wanted to make sure you get it.
I have to say a few words about the new directory structure of the dotScene related projects.
Many files were renamed, many new ones were added and I have also reorganized the directory structure of the dotScene related projects. Although DotSceneOctree and DotSceneInterface are separate projects, which must kept separately too keep them modular and which can be compiled together if required, they relate to the same thing, to dotScene. This is why I don't think the original separation which included a dotsceneformat and a dotsceneoctree directory in ogreaddons was well designed. There are also other projects like DotSceneViewer or DotSceneToDotSceneOctreeConverter which can't be categorized as something being related only to DotSceneInterface or DotSceneOctree. So they can not be put into one directory or the other. We have also introduced new projects. XmlNodeProcessor is the main phylosophy behind the new DotSceneInterface. Tinyxml was used by many of the dotScene projects before, but each project has had its own copy of it. Now tinyxml is kept as a separate project.
Another aspect is, that DotScene related projects were developed and tested in our own subversion repository, which have its own directory structure. As a result the current directory structure may be considered to be weird by some users of the projects. Anyway the projects were tested to compile in this structure and I haven't had the time to make new solution and project files configured with paths made especially for Ogre releasing. I can only hope that this directory structure is acceptable (at least temporarly) and it doesn't "frightens" anyone.
Taking into account all of these circumstances I think the snapshot I release should take place in ogreaddons under a directory DotSceneFormat, or something similar and directory dotsceneoctree should be tagged and then removed. (Anyway, all of these projects are about DotSceneFormat. ).
There are not going to be huge improvements in the next few months, only bug fixing and smaller improvements like finishing DotSceneInfo (perhaps finishing the integration of DotSceneOctree into DotSceneInterface, perhaps...). This is since we have an internal, smaller milestone of our game, coupled with a demonstration, timed to the middle of December.
I hope the new format will be welcomed and will satisfy many people in the Ogre community. I am open to any critics, suggestions, ideas or offering of cooperation from any member of the community.
I will paste this whole letter into the Ogre forums, as you were used to asked me to do so many times in the past.
I'm sort of confused the thread ended here.
I'm still rather newbie to Ogre, but I'm about to decide what format to use in my project(s) to allow artists to create their worlds in whatever program they want.
So - is there a new DTD for the DotScene format coming? And much more important - are the developers of the exporters (Blender, Maya, Max) somehow involved in this yet?
I'm currently evaluating OgreMax and I saw animation tags in the exported dotScene files which I cannot find in the current DTD. Will the new DTD be compliant to what OgreMax does now? And if so... do these tags exist in Blender exporter/s? And so on, and so on...
I hope somebody can clear these things a little up, sorry if should have misused this thread, but this is where I was expecting some results after reading the DTD preview. Thanks in advance!
You should check out the latest version of the directory of dotsceneformat from the Ogre cvs. There you can find the newest version of the dotscene related projects, the new .DTD and their (unfinished) documentation.
Please also read the previous posts in this forum ("new DotSceneLoader"), because all of your questions were answered before (or can be answered by checking out the latest version of dotsceneformat).
I have my Untitled.scene file and needed meshes in all possible directories related to the project, but after Ogre graphics mode window i hit OK and get the black screen..
I have my Untitled.scene file and needed meshes in all possible directories related to the project, but after Ogre graphics mode window i hit OK and get the black screen..
First please check out the new dotScene related projects from the Ogre CVS. You can find them under ogreaddons in the directory dotsceneformat.
If you need a hint how to use the new dotScene loader please read the readme.txt file under the directory "Source/Graphics Engine/trunk/main/SceneFormats/DotSceneFormat/Documentation".
You can also find sample code at "Source/Graphics Engine/trunk/main/SceneFormats/DotSceneFormat/DotSceneViewer". DotSceneViewer is a sample application parsing and displaying a scene from a .scene file.
For a description on the theory behind the parser system of the new dotscene loader you should read "Source/Common/trunk/main/XmlNodeProcessor/Documentation/Design concept & philosophy behind XMLNodeProcessor.txt".
You should also read the roadmap.txt and changelog.txt files to find out what features are currently missing or disabled in .scene. Under the Documentation directory you can find the dotscene.dtd file, which is the specification for the new dotscene format.
It is possible that you will be unable to compile my last commit to the cvs, however in the last few weaks I've been working on .scene again, and the features for the new commit are almost ready, so there will be a new more feature reach (with render window, render texture, multi render target, viewport, compositor and HDRCompositor parsing) and more stable version coming up soon.
If you read the previous posts you will find out, that currently there is a pause in the development for of dotScene related projects, because we have a roadmap to maintain in the development of our own game. And of course we are waiting for feedbacks on the new dotscene related projects too. However this won't be a too long pause, and until that point there are smaller developments requiring only 1 or 2 weeks (as in the current case with render targets).
It would be really nice to have a publicly available exporter for Maya which saves to the new dotScene format. Considering how usable and feature rich the new dotScene format is (even in its current state) this would lead many of us to using it. This is especially true, since the new dotscene format doesn't have any serializer. I will write the serializer part when the loader part is totally complete.
Looking forward hearing about you.
Cheers,
Balázs
i think it was on CVS under dotSceneOctree/plugins (for what i serached forums), but this directory on CVS doenst exist anymore (at least doesnt update here)
is there a equivalent (maybe under dotSceneformat?)
, which writes the animation data to a seperate file. 
