Fully Destructible Levels - New website and domain!

A place to show off your latest screenshots and for people to comment on them. Only start a new thread here if you have some nice images to show off!
Post Reply
User avatar
Aladrin
Orc
Posts: 465
Joined: Fri Mar 10, 2006 10:22 pm

Post by Aladrin »

Now it gets past that file but stops here:

Code: Select all

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.
User avatar
PolyVox
OGRE Contributor
OGRE Contributor
Posts: 1316
Joined: Tue Nov 21, 2006 11:28 am
Location: Groningen, The Netherlands
x 18
Contact:

Post by PolyVox »

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.
User avatar
Aladrin
Orc
Posts: 465
Joined: Fri Mar 10, 2006 10:22 pm

Post by Aladrin »

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.
User avatar
nikki
Old One
Posts: 2730
Joined: Sat Sep 17, 2005 10:08 am
Location: San Francisco
x 13
Contact:

Post by nikki »

Wow, esuvs. It looks very nice. Especially the updated screenshots on page 2. Excellent. Best of luck with the project! :)
User avatar
PolyVox
OGRE Contributor
OGRE Contributor
Posts: 1316
Joined: Tue Nov 21, 2006 11:28 am
Location: Groningen, The Netherlands
x 18
Contact:

Post by PolyVox »

@ Aladrin - Ok, great. And I'll try and fix some of those warnings so we can actually see where the problem is :D
User avatar
PolyVox
OGRE Contributor
OGRE Contributor
Posts: 1316
Joined: Tue Nov 21, 2006 11:28 am
Location: Groningen, The Netherlands
x 18
Contact:

Post by PolyVox »

nikki wrote:Wow, esuvs. It looks very nice. Especially the updated screenshots on page 2. Excellent. Best of luck with the project! :)
Thanks :D 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.
User avatar
nikki
Old One
Posts: 2730
Joined: Sat Sep 17, 2005 10:08 am
Location: San Francisco
x 13
Contact:

Post by nikki »

esuvs wrote:the lighting needs some smoothing
Yeah, it looks like a LEGO block model (no offence). :)
User avatar
PolyVox
OGRE Contributor
OGRE Contributor
Posts: 1316
Joined: Tue Nov 21, 2006 11:28 am
Location: Groningen, The Netherlands
x 18
Contact:

Post by PolyVox »

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 :D 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.
User avatar
milliams
Gremlin
Posts: 172
Joined: Fri Feb 16, 2007 1:47 am
Location: Portsmouth, UK
Contact:

Post by milliams »

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.
User avatar
Aladrin
Orc
Posts: 465
Joined: Fri Mar 10, 2006 10:22 pm

Post by Aladrin »

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 :D 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.
User avatar
PolyVox
OGRE Contributor
OGRE Contributor
Posts: 1316
Joined: Tue Nov 21, 2006 11:28 am
Location: Groningen, The Netherlands
x 18
Contact:

Post by PolyVox »

Did it create a file CEGUI.log (probably in the bin directory)? If so, what are the last few lines?
User avatar
Aladrin
Orc
Posts: 465
Joined: Fri Mar 10, 2006 10:22 pm

Post by Aladrin »

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.
User avatar
PolyVox
OGRE Contributor
OGRE Contributor
Posts: 1316
Joined: Tue Nov 21, 2006 11:28 am
Location: Groningen, The Netherlands
x 18
Contact:

Post by PolyVox »

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 :wink: I'll look into it...

Edit 2: Actually thinking about it, i'm not sure it even compiles with 0.4. Hmmm.....
User avatar
PolyVox
OGRE Contributor
OGRE Contributor
Posts: 1316
Joined: Tue Nov 21, 2006 11:28 am
Location: Groningen, The Netherlands
x 18
Contact:

Post by PolyVox »

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...

Image
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 »

What a difference! Awesome! :)
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
broli
Halfling
Posts: 48
Joined: Fri Mar 31, 2006 5:08 pm

Post by broli »

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â€
User avatar
PolyVox
OGRE Contributor
OGRE Contributor
Posts: 1316
Joined: Tue Nov 21, 2006 11:28 am
Location: Groningen, The Netherlands
x 18
Contact:

Post by PolyVox »

Don't worry you won't offend me :D 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 :D
User avatar
PolyVox
OGRE Contributor
OGRE Contributor
Posts: 1316
Joined: Tue Nov 21, 2006 11:28 am
Location: Groningen, The Netherlands
x 18
Contact:

Post by PolyVox »

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.
User avatar
Aladrin
Orc
Posts: 465
Joined: Fri Mar 10, 2006 10:22 pm

Post by Aladrin »

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 :wink: 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.
User avatar
Aladrin
Orc
Posts: 465
Joined: Fri Mar 10, 2006 10:22 pm

Post by Aladrin »

Yup, everything recompiled and still no go.
User avatar
PolyVox
OGRE Contributor
OGRE Contributor
Posts: 1316
Joined: Tue Nov 21, 2006 11:28 am
Location: Groningen, The Netherlands
x 18
Contact:

Post by PolyVox »

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.
User avatar
Aladrin
Orc
Posts: 465
Joined: Fri Mar 10, 2006 10:22 pm

Post by Aladrin »

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.
beaugard
OGRE Contributor
OGRE Contributor
Posts: 265
Joined: Sun Mar 25, 2007 1:48 pm
x 2

Post by beaugard »

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>
User avatar
PolyVox
OGRE Contributor
OGRE Contributor
Posts: 1316
Joined: Tue Nov 21, 2006 11:28 am
Location: Groningen, The Netherlands
x 18
Contact:

Post by PolyVox »

beaugard wrote:esuvs, this is starting to look really good!
Thanks! Plenty of hurdles to overcome yet though :D
Alik
Gnoblar
Posts: 22
Joined: Wed Mar 01, 2006 9:41 pm
Location: New York City

Post by Alik »

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
Post Reply