Hello.
Yea in both, also the "small" map is loaded and runs for both correctly. The problem is the rest of the maps. I just looked at the logs in the GUI, but i would like to see the logs in files. Do I need to set a config file to spawn such logs?


The scripting sounds really nice. But as for the game play I designed I am not sure this will fit or be enough flexible. I need to start understanding how does this work with the Ogre. But, in the end I need to have support for destructible terrains using the Ogre engine, we can talk about more details if you wish by e-mail.
I wrote in my blog a detailed step by step building process for the Thermite, maybe useful for some other users Itzjac-Angkor blog.
Finally, I would like to recommend you if we improve the portability by adding a couple of macros to support older compilers than one VS2010 uses, it will be really easy and helpful.

The logs should appear in the 'logs' directory under the working directory when you run the application. If you are using CMake with a seperate 'build' folder then the 'logs' directory is probably in there somewhere. Otherwise start at the project root and search for 'Ogre.html'.


I will make the scripting system as flexible as I can, but of course at the moment it is hard to say exactly how it will look. Of course, you also have the option of using PolyVox directly and integrating this with Ogre yourself, but then you will be duplicating a lot of work I have already done.


Interesting! I might add a link to it from the download page. Reading this, I notice that you used Bullet and OgreBullet. Actually I haven't used these for quite a long time and I don't think they are still working. If you compile Thermite with the '-DENABLE_BULLET_PHYSICS=OFF' option off (though CMake) then they won't be required for compilation. They can be tricky to build, so this should make compiling Thermite easier. Also, it is quite posible that this is the reason for the crash you are seeing as this code has not been maintained. Try compiling without them, and see if it helps.

I will fix the Bullet integration one day, but it's not high priority right now as I have already proved it can be done.



That could be possible, what changes do you suggest? As mentioned, I used to have macros which allowed Boost to be used instead and I also supplied a copy of some Boost headers with the PolyVox code. I had my own smart pointer called POLYVOX_SHARED_PTR (or something) which was just a define for the boost or std version. But this meant it had to be everywhere in the code and was a bit messy (as no-one used it except me).

But I don't mind if in one of the main headers (like typedef.h) we had:

#ifdef OLD_CPP_SUPPORT
#include <boost/shared_ptr>
#define std::shared_ptr boost::shared_ptr
#endif

Would that kind of thing work? It avoids changing too much of my code. Of course, I wouldn't say it is good practice but if it is off by default then maybe it is ok

Thanks for the information, should've noticed the CMake information but I missed it.
I got running the compiled version of this, no more Bullet dependencies. I located the logs and still I got the crash when loading the terrains as before (the small one still works for both API's).
I found an exception in the Ogre log which I will investigate. If you need the rest of the logs, I can send you them. The rest of the logs don't show any error.



Every time a .material script is parsed (DesertSurface.material for instance) both exceptions are called.



Sure, that should be enough. Checking the _MSC_VER would be the same

I've just checked my log and don't see this error, though I'd have to do some more invstigation to find out the cause.

Do you also get this error when parsing 'ShadowMapReceiverForWorldMaterial', which is the one used by the castle? You can actually change which materials are used by editing the .map files (which are xml). If you open desert_(medium).map you can change the references to 'RockMaterial' and 'DesertSurfaceMaterial' to 'ShadowMapReceiverForWorldMaterial'. The result might look strange, but at least you can see if it works. You can also try using 'BaseWhiteNoLighting' as the material, this is a plain white material built into Ogre.

Though to be honest I'd be suprised if this causes the crash... Ogre would normally just use a plain white fall-back material if it couldn't load the specified one. Because you said the crash occurs while extracting the surface it would seem more likely that the bug is in the surface extractor code. As a quick test, I suggest clearing the volume to empty after you load the data into it. Find the VolumeResource::loadImpl() function in Thermite and add the following loop before the call to tidyMemory():



Note: MaterialDensityPair44 is a new addition to PolyVox/Thermite. If you don't have that class in your version then the code in the loop can simply be:



Obviously you won't see the volume when you run the game now, but does it load sucsessfully? If so, try just setting the edge voxels to zero (the edges are usually where the algorithm has problems):



Any luck?



Ok, well I've added this code snippet to TypeDef.h. I don't really have a way to test it though so I would be suprised if it just works (the order of headers will be important, and there is still the issue with <cstdint>). Maybe you can send a patch of the further changes you have had to make?

Actually, after double checking it doesn't work for the castle either


This change works, everything looks white of course, I've just tested the castle and desert maps.


With the updated VolumeResource::loadImpl() function and using original settings for the castle, dessert and even the hills maps it works. It seems I have the latest Thermite, no problem using MaterialDensityPair44.


I tried like this and using the original map configuration still crashes.

But hold on, after looking more carefully I noticed the mentioned Ogre exceptions are logged while starting up. So even if this works using the white material, some info is missing or a GPU related problem. The best is to check the whole Ogre log. This problem looks a simple resource file missing by now .



And continues the same for the TriplanarTextureFP, ShadowMapReceiverForWorldFP and the already known DesertSurface.material.

EDIT: I uploaded an attachment but don't think it works...

EDIT2: How did this ever work when I compiled with the Bullet support ?

Ok, so changing/erasing the voxels makes no differnce, but using the BaseWhiteNoLighting material fixes it. So in other words it does appear to be material related. There are some other basic materials in old-materials\basic\ which you could try - at least this will get back your lighting and let you see voxels in different colours:



By the way, I notice at this point that the engine crashes if you spell the material name wrong. Something to keep in mind.

If these basic materials work then I suspect the issue is Cg. I do remember having a problem a while ago when I had two conflicting versions of Cg on my system.

I don't have time to write more now, but I'm going to upload a new build of Thermite which you can then compare to the version you have built from source (the build you downloaded from the website is probably a few months old). You can compare the Cg.dll version, etc, and try swapping some over. You can also then compare the log messages.

Unfortunatly I'm not actually going to be able to do this, at least for the foreseeable future. I'd forgotten how much effort it was to prepare a binary release and make sure it runs on all systems with the .dlls, redists, etc. I just gave it a quick try and it didn't work, and unfortunatly I don't have much time at the moment to investigate.

However, I do get the impression that your problem is with Cg/Ogre rather than Thermite. If you can get the Red/Green materials in my previous post to work then it does indicate this. How familiar are you with Cg/Ogre/shaders? You might find that if you cut the Cg shader down to return a single colour then you have more luck getting it to compile, and you could take it from there. Start with something like DesertSurface.material as the ShadowMapRecieverFor World one is a lot more complex.

Otherwise, you don't actually have to use Cg at all. Ogre supports shaders written in HLSL/GLSL so you could try using these? Otherwise you just have to wait until I give Thermite some more attention. I'm working on a seperate prototype project at the moment which I hope to merge into Thermite in a couple of months...

No problem, I will try to find and fix on the CG/Ogre side.

I'm not familiar, but this feels like a perfect time to start understanding shaders. During the week I'm really busy, I will start testing during weekend. Will post something as soon as I find the problem or fix it.
Thank you.

Yes, I got working using basic color materials.


I think that will take more time to learn and port, if there is no other way to make this work, then I will go for the HLSL/GLSL solution.

I read a couple of threads in the Ogre forum mentioning the same compile problems for the Cg shaders, in general if one parameter is no used then it is optimized and removed, a compile error will be produced.
Lets take as an example DessertSurface.material (used in Dessert map).
The parameter uniform float4x4 textureMatrix, is one of the compiler errors.


which directly point to the SingleProjectedTextureFP.cg, from what I can noticed, the parameter is being used to compute texCoords, I can't see where an optimization would happen here.

Since I couldn't find any reason for the optimization to happen, I started simplifying the shader code and removing parameters, those logged as errors, for the same Dessert map. No more default parameters where used and a simple color was returned and no more compile errors where found for the cg programs; there where a couple more for the old materials though:


I tried removing those inheritance from the old materials, which I suspect is an old resource missing, couldn't find any file containing such definition. Would be nice to fix or submit the missing resource if that is the case. Finally, any compile errors were produced but the crash still happened . I can send you the three logs to double check this issue.

After this tests I got confused if my video card (ATI 4650) really supports those shaders, but sure! Consider when I got your demo it perfectly runs, the compiled one using basic materials it runs. I'm starting to suspect there is a tricky compile flag or something. What do you think?

NOTE: those compile erros related to the old materials are also logged when running the demo I download from your site, has nothing to do IMO.

[Edit:]NOTE: Please see my next message as well as I made a mistake in the file

It's good to see you are still working on this

One thing you need to know is that on startup Ogre will process all the resources which in finds in it's path, even if they are not actually used. For example, it seems the brick.material is an old and broken material which I should probably have deleted. Ogre is still trying to load it, and failing, but it doesn't matter because it isn't used.

For your main problem, we now know that the simple Red and Green materials work. However, these materials do not make use of any shaders (they are fixed function) so I suggest we now test the most basic possible Cg shader. It may be that something is fundamentally broken with the Cg version on your system (some kind of dll conflict perhaps).

I have uploaded a zip file containing a folder called 'test-materials'. You can get it here:

http://www.thermite3d.org/temp/test-materials.zip

Extract it and place 'test-materials' next to 'materials' and 'old-materials'. Then edit your 'desert_(medium).map to use "CgTestMaterial" for both the materials. E.g:



Please use the DirectX render system for this test, and it should show up bright orange.

If it crashes, then we can instead test "HLSLTestMaterial". This is the simplest possible HLSL material:



Be sure to use the DirectX render system, it should show up purple.

Please let me know how these tests work out...

One other question, do all the Ogre samples build and run correctly for you? I'm not sure which ones are using Cg, but have you noticed any problems?