Ogre Forums

Posted: **Mon Apr 23, 2007 1:26 pm**

Now it gets past that file but stops here:

Linking CXX executable Xml2Volume
CMakeFiles/Xml2Volume.dir/source/ConverterVisitor.o: In function `ConverterVisitor::parseSubmeshOptions(std::basic_string<char, std::char_traits<char>, std::allocator<char> >)':
ConverterVisitor.cpp:(.text+0x507): undefined reference to `boost::program_options::options_description::options_description(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned int)'

-snip-

Code: Select all

collect2: ld returned 1 exit status
make[2]: *** [Xml2Volume/Xml2Volume] Error 1
make[1]: *** [Xml2Volume/CMakeFiles/Xml2Volume.dir/all] Error 2
make: *** [all] Error 2

It seems to be not finding the library now. /usr/lib is in my ldconfig and I've tried export LD_LIBRARY_PATH=/usr/lib

The only reference I could find about this on the net was that the libraries have to be specified in the right order.

http://lists.boost.org/Archives/boost/2005/09/93492.php
http://cygwin.com/ml/cygwin/2005-11/msg00158.html

I don't know enough about cmake to figure out where this is specified, though.

Posted: **Mon Apr 23, 2007 1:58 pm**

Ok, it's not immediately obvious to me what the problem is there. I'll talk to my Linux and CMake guy and see if it works on his system. He won't be available for a couple of days though.

In the mean time, the only part of the system which actually uses boost is the mesh converter. So hopefully you can get the rest of the engine to compile ok if you skip this part. Try opening CMakeLists.txt in the the top directory and putting a '#' at the start of line 9 so it reads:

#ADD_SUBDIRECTORY(Xml2Volume)

Then rebuild. Note that CMake caches some stuff so you might need to remove CMake generated files in several directorys before this works. Hopefully you can spot them by the date.

At this point I can give a useful tip I should have mentioned before. Rather than running 'cmake .' from the top directory, you can create a subdirectory called 'build' or something similar, change into this directory, and run 'cmake ..' (note two dots this time). This will put all CMake cache files and object files in this directory making them easier to delete all at once. Actually I might as well add this empty directory to subversion and update the install instructions appropriately.

Posted: **Mon Apr 23, 2007 2:08 pm**

Ah, okay. I removed the whole dir, re-checked it out from svn, and then did the build dir thing.

Commenting that line out does indeed let the rest of it build.

I'll mess with it and see if I can get that last piece to compile.

Posted: **Mon Apr 23, 2007 2:23 pm**

Wow, esuvs. It looks very nice. Especially the updated screenshots on page 2. Excellent. Best of luck with the project!

Posted: **Mon Apr 23, 2007 2:28 pm**

@ Aladrin - Ok, great. And I'll try and fix some of those warnings so we can actually see where the problem is

Posted: **Mon Apr 23, 2007 2:32 pm**

nikki wrote:Wow, esuvs. It looks very nice. Especially the updated screenshots on page 2. Excellent. Best of luck with the project!

Thanks

I need to work on the visual appearance next - the lighting needs some smoothing and it would be cool to get some dynamic shadows in there. Also needs some nice 3D materials. It's not going to look like Unreal 3 but I'm pretty sure I can polish the graphics quite a lot.

Posted: **Mon Apr 23, 2007 2:38 pm**

esuvs wrote:the lighting needs some smoothing

Yeah, it looks like a LEGO block model (no offence).

Posted: **Mon Apr 23, 2007 3:03 pm**

nikki wrote:
esuvs wrote:the lighting needs some smoothing
Yeah, it looks like a LEGO block model (no offence).

Agreed. Probably I get sued by Lego now

But I should be able to use averaging or filtering techniques to generate better normals - it's just a case of doing it fast enough. Or pre-computing, which may not be too hard as the same structures tend to come up repeatedly.

Posted: **Mon Apr 23, 2007 7:36 pm**

Hey Aladrin. I'm the Linux CMake guy. The linking error was caused by a mistake in the CMakeLists.txt file. Do another 'svn up' and try again.

Posted: **Mon Apr 23, 2007 8:09 pm**

milliams wrote:Hey Aladrin. I'm the Linux CMake guy. The linking error was caused by a mistake in the CMakeLists.txt file. Do another 'svn up' and try again.

Awesome, it compiles now. Next error

I installed it to my home directory in ~/thermite and did export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:~/thermite/lib and executed bin/Engine. It seems to go great up until this point:

Code: Select all

Creating MenuState...
mGUIRenderer = 142276680
Texture: TaharezLook.tga: Loading 1 faces(PF_A8R8G8B8,256x256x1) with  hardware generated mipmaps from Image. Internal format is PF_A8R8G8B8,256x256x1.
terminate called after throwing an instance of 'CEGUI::FileIOException'
Aborted (core dumped)

It's all installed as my user, so there shouldn't be any permissions problems. I can't run it as root from there because it won't open my X display.

I didn't really want to install it in /usr, but I can if that's the next troubleshooting step.

Posted: **Mon Apr 23, 2007 8:52 pm**

Did it create a file CEGUI.log (probably in the bin directory)? If so, what are the last few lines?

Posted: **Mon Apr 23, 2007 9:19 pm**

esuvs wrote:Did it create a file CEGUI.log (probably in the bin directory)? If so, what are the last few lines?

Gah, I'm slow today...

Code: Select all

23/04/2007 15:03:26 (InfL2)     ---> Start of definition for widget look 'TaharezLook/TabButton'.
23/04/2007 15:03:26 (InfL2)     ---< End of definition for widget look 'TaharezLook/TabButton'.
23/04/2007 15:03:26 (InfL2)     ---> Start of definition for widget look 'TaharezLook/TabContentPane'.
23/04/2007 15:03:26 (Error)     Exception: XercesParser::parseXMLFile - An error occurred at line nr. 3306 while parsing XML file 'TaharezLook.looknfeel'.  Additional information: Attribute 'layoutOnwrite' is not declared for element 'PropertyDefinition'
23/04/2007 15:03:26 (Error)     WidgetLookManager::parseLookNFeelSpecification - loading of look and feel data from file 'TaharezLook.looknfeel' has failed.

Posted: **Mon Apr 23, 2007 9:22 pm**

I'm going to take a guess that you built against CEGUI 0.4, rather than 0.5? The format of the XML files changed between these two versions...

Edit: And yes, the CMake script probably should check

I'll look into it...

Edit 2: Actually thinking about it, i'm not sure it even compiles with 0.4. Hmmm.....

Posted: **Mon Apr 23, 2007 9:38 pm**

I've now fixed the lighting - it's a lot smoother. Compare the image below to the one on page 2. It's also slower of course (though only when changing geometry, not when flying around) - I think i'll make this user configerable.

Right, now I must stop adding features and clean the code up a bit...

Posted: **Mon Apr 23, 2007 9:43 pm**

What a difference! Awesome!

Posted: **Mon Apr 23, 2007 10:01 pm**

I know this is a proof of concept and all but in the end people want to know how useable and scalable it is. I'm not trying to bash you or anything but when I look at this I think of CSG. Since yours is voxel based it can be indeed much more flexible, but voxels aren't really straight forward when you're looking at very artistic triangulated and rather complex environments unlike the â€œprevious-genâ€

Posted: **Mon Apr 23, 2007 11:04 pm**

Don't worry you won't offend me

You raise some valid points - as you may be aware the CSG method has been sucessfully used in commercial games (Red Faction). I don't know much about it but you can do real CSG as seen in Red Faction and also here:

http://www.melax.com/csg/index.html

Alternatively you can fake it by using the stencil buffer (I think) to hide parts of the geomerty. Obviously this breaks when you introduce collision detection/physics because the world isn't really being modified, but see this library:

http://www.opencsg.org/

I think the second approach is pretty useless for a game, but is used in CAD and modelling applications. Some things that the voxel scene manager can do which CSG can't:

1) Simple and robust. Although I've never implemented it I can imagine that mesh based CSG is very difficult to do.

2) Burning/Dissolving. I look forward to implementing this - it should be quite easy to have the geometry slowly eaten away by fire/acid. Flamability and solubility could be specified on a per voxel basis.

3) Geometry which heals. You shoudl be able to blow things away and then see them grow back.

4) Collision detection which is so easy I could (and sometimes do) laugh. Integrating an external physics engine is likely to be a lot harder, however.

How will it compare to a CSG based engine? I really don't know. The voxel stuff will never lok as good or as detailed as modern games but there's nothing to stop you combining it with more conventional approaches. You can combine it with non-destructible static geometry and all the entities in the world will be normal Ogre meshes.

Basically, you'll just have to wait and see

Posted: **Mon Apr 23, 2007 11:35 pm**

jacmoe wrote:What a difference! Awesome!

Thanks

It now works by using image processing approaches to find the normal from the underlying volume data, rather than generating the triangles and using the cross product to find the normal. It also solves a problem I was having with the normals not lining up at block boundaries.

Hopefully this will also benefit physics when I come to implement it.

Posted: **Tue Apr 24, 2007 12:43 am**

esuvs wrote:I'm going to take a guess that you built against CEGUI 0.4, rather than 0.5? The format of the XML files changed between these two versions...

Edit: And yes, the CMake script probably should check I'll look into it...

Edit 2: Actually thinking about it, i'm not sure it even compiles with 0.4. Hmmm.....

I don't even KNOW what version CEGUI was... It was whatever Kubuntu had. Some weird number. So I removed that, downloaded the source and installed it. Recompiled thermite.

No change.

So I recompiled Ogre again from source. Recompiled thermite.

No change.

I may have forgotten to run ldconfig before I recompiled Ogre, so I'm doing that again... But I'm not real hopeful here.

Posted: **Tue Apr 24, 2007 1:09 am**

Yup, everything recompiled and still no go.

Posted: **Tue Apr 24, 2007 10:47 am**

I'm a little perplexed - it's odd that the error seems to come from inside CEGUI. It complains that the XML looknfeel file isn't valid - that's what made me suspect the wrong version of CEGUI.

Anyway, I've been meaning to install Linux soon and fortunatly for you I tend to use kubuntu

So I'll see if it works for me. Am I right in thinking that you installed packages for CMake and Boost while you built Ogre and CEGUI from source? Just so I can try and match your configuration...

It might be a few days before I get it installed (I'm expcting Vista at some point too so ideally I do them at the same time) so I'll let you know what happens.

Posted: **Tue Apr 24, 2007 11:29 am**

esuvs wrote:Am I right in thinking that you installed packages for CMake and Boost while you built Ogre and CEGUI from source? Just so I can try and match your configuration...

Yeah. I got desperate at one point and installed -all- the boost packages from the repository, so I've got all the optional stuff. I doubt that'll matter, but for completeness' sake, I figure I'll mention it.

Posted: **Tue Apr 24, 2007 3:05 pm**

esuvs, this is starting to look really good!

... and by the way, thanks for the csg links. I had no idea there was an opencsg. Although I think you are right about the problems of using this in strictly real-time simulations, I think it could be done in "near-realtime", in a background thread. So you can blow things up, just not very many things very often.

<EDIT>
uhm, it seems opencsg was not exactly what I guessed it would be... still very nice, though.
</EDIT>

Posted: **Tue Apr 24, 2007 9:33 pm**

beaugard wrote:esuvs, this is starting to look really good!

Thanks! Plenty of hurdles to overcome yet though

Posted: **Thu Apr 26, 2007 5:06 pm**

esuvs wrote: How will it compare to a CSG based engine? I really don't know. The voxel stuff will never lok as good or as detailed as modern games but there's nothing to stop you combining it with more conventional approaches.

Have you thought about breaking down and embedding the surface geometry in your voxel cubes? I think that would solve your rendering problems. That way you could have a much higher resolution surface mesh than the actual voxel mesh, and you'd be back to rendering triangles, which are obviously better understood and supported. You could still have all the neat effects involved with removing voxels; you'd just have update the surface geometry.

The trickiest part would be generating polygons for exposed internal surfaces, but there is a paper on this: http://graphics.ethz.ch/~mattmuel/publi ... gi2004.pdf .

Alec

Ogre Forums

Fully Destructible Levels - New website and domain!