new DotScene loader

[ProfesorX]

@dudeabot
Now it is in dotsceneformat\Source\Graphics Engine\trunk\main\SceneFormats\DotSceneFormat\DotSceneOctreeSceneManager

directory

[dudeabot]

thanks

where can i get Plugin_DotSceneManager.dll?

[dudeabot]

also is there a callback i can use when loading the dotscene using DotsceneInterface?

my code (based on dotsceneviewer):

Code: Select all

	try
	{
		LogManager::getSingleton().getDefaultLog()->setLogDetail(LL_BOREME);
		mDotSceneInfo	= 0; // Important to set it to zero, otherwise loader will freeze.
		mSceneProcessor->load("poli3d.scene", "General", mSceneMgr, mWindow, NULL, false, false, &mDotSceneInfo);
		// DEBUG PART!!!
		// Disable all lights.
		//mSceneMgr->setDisplaySceneNodes(true);

		SceneManager::MovableObjectIterator lit = mSceneMgr->getMovableObjectIterator("Light");
		while (lit.hasMoreElements())
		{
			MovableObject *pLight = lit.getNext();
			pLight->setVisible(!pLight->isVisible());
		}

		//SceneManager::MovableObjectIterator movableObjectIter = mSceneMgr->getMovableObjectIterator("Entity");
		//while (movableObjectIter.hasMoreElements())
		//	movableObjectIter.getNext()->setVisible(false);
		// END OF DEBUG PART!!!

		// Check for load errors/warnings/infos.
		dsi::DotSceneInfo::LoadLogVectorIterator it = mDotSceneInfo->getSceneLoadLog();
		String errs;
		while (it.hasMoreElements())
			errs += it.getNext() + "\n";
		if (errs != StringUtil::BLANK)
		{
			OGRE_EXCEPT(Exception::ERR_INTERNAL_ERROR,
				"The following errors occured during scene loading:\n" + errs,
				"dotSceneViewerApplication::createScene");
			return;
		}
		// Go on if all is OK.
		//			mWindow->setDebugText("PRESS 'H' FOR HELP");

		// TODO: further develop this, concatenate camera name with common name prefix, perhaps give user the opportunity to
		// choose main camera name manually.
		// Find out if there's a main camera in the scene after parsing.
		Camera *pMainCam = NULL;
		SceneManager::CameraIterator cit = mSceneMgr->getCameraIterator();
		while (cit.hasMoreElements())
		{
			pMainCam = cit.getNext();
			for (int n = 0; n < 8; n++)
			{
				String camName = pMainCam->getName();
				String mcName = "mainCam";
				LogManager::getSingleton().logMessage("##Camera"+StringConverter::toString(n)); 
				LogManager::getSingleton().logMessage(pMainCam->getName()); 
				if (strstr(camName.c_str(), mcName.c_str()) != NULL)
				{
					
					ColourValue bgCol = mWindow->getViewport(0)->getBackgroundColour();
					mWindow->removeAllViewports();
					Viewport *pView = mWindow->addViewport(pMainCam);
					pView->setBackgroundColour(bgCol);
					mCamera = pMainCam;
					break;
				}
			}
		}
	}// End of try

i need this to make collision,

thanks

[ProfesorX]

dudeabot, i answer your PM, as i say there, you need to compile the DotSceneManager source code yourself, the code is in the path i put you in my above post.

[yaskil]

Hi,

Nice work. Well done. Can I use your code in a commercial project? What are the restrictions?

[leandro]

Hi, I was using the old version of DotScene in my project in Linux (Fedora) and now I want to upgrade to the new version. I've read in the readme.txt that I need to compile the source code because there is no make files.So my cuestions are: Is it difficult to compile? Which files do I need to compile? Any suggestions?

Thanks

[Chewi]

Sorry for the late reply but I've been helping wolverine to get things going in Linux. Expect some news in the next few weeks.

[leandro]

Thanks !!

[Chewi]

Thought you guys might like to see this. DotSceneViewer running the (rather messy!) test map under Linux.

http://www.aura-online.co.uk/~chewi/dsv-linux.png

I'm about to send these latest changes to wolverine. He needs to merge them with his latest changes before they can be committed.

[PiCroft]

Hi guys.

I have a very odd error with DotScene.cpp. I've been using it up till now perfectly, with no problems.

Just recently, after unsuccessful tinkering with ODE and OgreODE, I went back and tried an earlier version, only to find that my DotScene.cpp was giving me an error.

Code: Select all

void CDotScene::parseDotScene( const String &SceneName, const String& groupName, SceneManager *yourSceneMgr, SceneNode *pAttachNode, String sPrependNode)
{
	// set up shared object values
	m_sPrependNode = sPrependNode;
	mSceneMgr = yourSceneMgr;

	TiXmlDocument   *XMLDoc;
	TiXmlElement   *XMLRoot, *XMLNodes;

	try
	{
		DataStreamPtr pStream = ResourceGroupManager::getSingleton().
			openResource( SceneName, groupName );

		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
			LogManager::getSingleton().logMessage("[dotSceneLoader] The TiXmlDocument reported an error");
			delete XMLDoc;
			return;
		}
	}
	catch(...)
	{
		//We'll just log, and continue on gracefully
		LogManager::getSingleton().logMessage("[dotSceneLoader] Error creating TiXmlDocument");
		delete XMLDoc;
		return;
	}

Note: this isn't the entire parseDotScene() function. Just the relevant parts.

Its telling me that the variable XMLDoc is being used without being initialised. It steps through the try{..} block up till the line:

ResourceGroupManager::getSingleton().openResource( SceneName, groupName ); at which point it steps out of the try{..} block and then goes to the catch block, where when it tries to delete XMLDoc, it throws the aforementioned error.

Now, I realise that it may well be due to a problem finding the resource in question, but I can't see how as I haven't altered the directory structure, the models or .scene files in any way. Although I'm looking into checking if my resources are not being found properly, is there anything else which might cause this error?

[btmorex]

You need to modify the catch to print out more than "[dotSceneLoader] Error creating TiXmlDocument". Catch OgreException and then call getFullDescription() on it.

Aside from that, the delete in that catch block is a bug since indeed it might get triggered when XMLDoc is uninitialized.

[PiCroft]

Thanks dude.

As it turns out, it was indeed a problem with where I had put the .scene file. At least I think it was.

[aoos]

hi, i get compiler errors trying to compile this code , my compiler cant find the include files (
#include <Ogre/OgreString.h>#include<Ogre/OgreVector3.h> #include <Ogre/OgreQuaternion.h>) are they in the ogre Sdk or i haven't link them right? i have the 1.4.6 version!

[aoos]

Noone? its essential to find how to compile and use this code can anyone help me?

[triton]

Noone? its essential to find how to compile and use this code can anyone help me?

You need to add the OGRE SDK include folder to the include paths on the project.

[6i]

hi,
i was just wondering, is the loading of the userdata handled (if so, i would be interested how to get to it - structures etc.) or do we have to make our own processors and recompile dotSceneInterface with them?
as i peeked into the implementation of the DotSceneProcessorImpl_v1_0_0, i've find no trace of processor for the userdata element (exported from blender), even though it seamed, that i can't (reasonably) make a subclass of it adding only some elementprocessors without (re)implementing the whole thing..

[6i]

i've got some answers from our well-honored project-maintainer, wolverine, in PM and we both agreed to post it to the forum, so anyone dealing with similar problems might want to read it, too:

Userdata is not handled currently and it won't it is up to the user to handle it Wink, however you can easily implement your own xmlnodeprocessor listener and register it to handle that data. There is no need for recompilation. For more information on listeners please refere to the source of XmlNodeProcessor.h/.cpp there are doxygen compatible comments, and they are really useful.
Unfortunatelly the code which is currently in the repository lacks the interface to register such a listener when a processor tree was built. Although the interface for registerting listeners is present in XmlNodeProcessor itself, the interface to query a given processor from a tree builder is not present in that old version which is currently in the repository. Also this interface is not present in DotSceneInterface_v_1_0_0 itself. So you can register a listener, however you can't acquire the object you have to register for. :-S
This interface has been written, and it is present in the new versions, which I haven't commited to svn yet. Sorry.

Anyway in the near future I will have to do a commit.

[DaHoC]

Hi,
I got an error message (something like):

Code: Select all

DotSceneLoader.cpp:786: Error: No matching function for call of »TiXmlElement::Attribute(const std::basic_string<char, std::char_traits<char>, std::allocator<char> >&)«
Candidates are: ...

and needed to adjust the dotSceneLoader.cpp code (http://www.ogre3d.org/wiki/index.php/Ne ... ene_Loader) to get it working with trunk ogre (27.06.2008) and tinyxml (version 2.5.3) at 6 lines around 787, 786, 794, 795, 802, 804 in the following way: I replaced

Code: Select all

XMLNode->Attribute(attrib)

with

Code: Select all

XMLNode->Attribute(attrib.c_str())

at each of the lines.
Perhaps it was due to some api change in tinyxml or me using linux, but with the adjustments it now works fine.

Just wanted to drop a note in case someone else has the same issue.

[Chewi]

DaHoC, I think that was one of the many changes I sent to wolverine. I don't think he's committed my stuff yet but I'm not sure since I've been busy getting married. If he hasn't, I think you'll need to do a lot more than that to use this stuff in Linux. Hopefully I'll get back to it soon.

[MAITVN]

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

Greetz,
JeDi

[wolverine]

Hi Everyone,

It has been a long time since I have last made a post to the Ogre Forums.
This is because I've been quite busy with running my company (and I am still so).

So here is a letter I have received (I have deleted the writer name, since I'm not sure if he would like it to be displayed here).

Hi, wolverine and thanks for your work

I asked in the forum but nobody answered me.

I'm using the blender .scene exporter and mesh exporter from the forum (patched 31 Agoust) and the official dotSceneFormat from svn but the loader fails to set the right orientation because in the dtd v 1 the quaternion element must be enclosed in an orientation element. The blender dotScene exporter instead puts the queternion element directly in the node element. I changed the script and now it works.

Are there other differences between the exporter and the dtd?? Is there an official exporter fully compliant with the last dtd??

tnx for your attention

And here is my answer to it:
Hi ...,

Sorry for being unaware of your post, but I didn't get notification mails about it.
I don't know why the Notification of the Ogre forums isn't working, everytime someone writes in to the forum "new dotScene loader" I have to get a notification mail about it. :-S
I am really busy nowadays with the development of my company's next game, so I don't read the forums if I don't get a notification mail.
Anyway thanks for your question. As long as I know the Blender exporter is a really old one, and it was officially developed for the old dotScene v0.2.0 format.
Currently no exporter available for the new dotScene format. The latest dotSceneInterface which is in the svn repository also lack any serialization functions. Although serialization have been implemented since by another programer, but I didn't had the time to merge his code with mine and commit it into the repository. (I'm going to have more time after the end of December when we have finished with our current project.) However this serialization only includes serialization from a running Ogre SceneManager (e.g. saving a game) and not exporting from modelling softwares. However you can feel free to implement an exporter if you wish.

There are a huge number of differences between the old format and the new format. The file in the repository changelog.txt consists information about this. You should also read the file Readme.txt for more information and take a look at the .dtd itself.
Current this (so the offical v1.0.0 found in the svn repository) dotSceneInteface implementation supports the loading of the most elements and attributes compared to all other implementations. And this implementation is really modular and flexible, you can easily add your own element processors, or modify the working of an existing one, without recompiling the code itself. You can also attach listeners to existing nodes to react to loading or parsing events.
Although I haven't had the time to commit it, a few people also managed to compile the full source under Linux and MinGW. We have to compile it under Mac for our new project, so I'm going to commit the project/makefiles for all available platforms in Januar.

Cheers,
Balázs


I am also trying to brief answer some of the questions which have arised since I have last checked the forums:

- Sometimes I get notification mails about the forum, sometimes I don't. :-S
- I don't have the time to always watch the forum. Sorry for it, if you have a really urgent matter please send me a PM.
- As you could read above there is an already existing, untested, uncommited serialization.
- There is no exporter available currently for any modelling software. Any volunteering for it is welcome.
- DotSceneInterface is well tested (dotSceneViewer is not as stable) and it is indeed capable of serving in a commercial project. We are ourselves using it in our games!
- There is an aready existing, uncommited linux port, however it is going to be commited soon (2009 Januar) along with the port for Mac.
- The license of the code is LPGL, as you can read it at the beginning of every source file and in the file lgpl.txt. Its the same as for Ogre. I short it means that you can use it for commercial projects if you link it to them dinamically and if you release any modifications you make to the source of the DotScene related projects itself. You don't have to release the source of your own project.
- If you try to open a non-existing scene file (or a scene file with a wrong path), you are going to receive error messages, complaining about the fact that dotSceneViewer can not find the given scene file in any resource group. This is normal.
- There are a lot of questions on the Ogre forums which have been already answered. Either by me or someone else on the forums or by the readme.txt file or the svn logs in the repository. Please refer to these information sources first.

Currently I am having hard times with developing our latest game (which is Ogre, CEGUI and dotSceneInterface based). This is why I was compelled to temporalily derelict the Ogre community. I have to apologize everyone for that. You know how game developing works, we have a time-lag and the game must be ready by the beginning of December.

Sorry, currently no screenshots available from our newest game (although it uses dotSceneInterface too , and I'm going to post a few when it gets ready ), however if you are interested about some screenshots from one of our older games, or simply about what you can do with Ogre, or what we do, have a look at our website:

http://www.breathingbytes.com

In January 2009 I hope I will have the time to commit all the changes of the dotScene related projects to the svn repository (either done by me, by someone else at my company or by a third party) and answer all the outstanding questions (and update the Wiki pages!).

Cheers,
Balázs

[jettero heller]

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.

You will see on 5th of October.

Hi.
Can someone show me how to extend the dotSceneLoader??
I've my own tags for physics and I made the XmlNodeProcessor for all the tags.
Now I've to register the processors with the dotSceneNodeProcessorTreeBuilder but the registerElementProcessor() method is declared protected.
I know I can extend the dotSceneNodeProcessorTreeBuilder class but there isn't way to give my own TreeBuilder to the DotSceneProcessorImpl.
Should I derive the DotSceneProcessorImpl and add my own class to the DotSceneProcessor?? and which method should I use?

I'm a bit confused...

tnx..

[jettero heller]

Q: How can I extend an existing XML processing tree?
A: In most cases, you only have to inherit from its TreeBuilder class so that you override its buildTree() function.
There you can create your processor objects and register them to the appropriate branches in the existing tree.

[jettero heller]

not solved yet

I thought to derive various classes and override some methods but some attributes are private (see DotSceneProcessor class) so I can't use them in my derived class... I'm stuck... any idea???

tnx for your attention.

[metaldev]

why dont you just change the loader to do whatever you need it to do?

no scene loader is going to be perfect, there are just too many exceptions for any given application. I'm pretty sure the code is just meant to be a starting point.

maybe I'm not sure what you are asking?