D3d Prt Engine

#1 I know what the problem is, I don't know how to fix it without trying it out, unfortunatly, and I can't mess with it right now.

This is what is happening though, the Torque Memory Manager redefines 'new' and as I write this I realize that I should really do a resource of an overview of how this all works and how to change it etc. Anyway, it redefines new because Torque's memory manager allocates a big chunk of space and then when new is called from Torque it passes that space out so that you are not constantly allocating and unallocating memory at a system-level. This is done for many reasons, it is better for performance, it lets you find memory leaks, and it lets you control and see exactly how much memory your game is using, and where it is getting used.

This is one possible fix! It may not be the best fix, but it is one possible fix:

Compile with 'TORQUE_DISABLE_MEMORY_MANAGER' defined, and in winMemory.cc find the place where it defienes new, it should look like this:

void* FN_CDECL operator new(dsize_t, void* ptr)
{
   return (ptr);
}

replace it with this

#if !defined(TORQUE_DISABLE_MEMORY_MANAGER)
void* FN_CDECL operator new(dsize_t, void* ptr)
{
   return (ptr);
}
#else
#include <new>
#endif

I don't know if that will work for your needs, but it's worth a shot. Good luck.

#2 An article on this stuff would be great.. but not i priority i would think :p

#3 Thanks for the quick answer!

It worked!!! :D
Yesterday, I have compiled with TORQUE_DISABLE_MEMORY_MANAGER defined but I forgot to disable the new operator...

Thanks again


PS: An article would be great ;)

#4 Ask and ye shall recieve

Resource

#5 @David

any chance on information on what u did to get it going , am interested in adding this in as well , was it just a case of reading the DX documentation ?

regards
Kenneth

#6 Hi,

Dx documention (plus the article "PRT for Real-Time Rendering in Dynamic, Low-Frequency Lighting Environments" of the authors Peter-Pike Sloan, Joan Kautz and John Snyder) and the DX samples are a good start.

My PRT implementation in TSE isn't finished yet. But I will try to explain what I'm doing.

I built a PRT manager. This object is similar to class SceneLight in many ways. It collects all objects that will be used in PRT simulation (only static objects, terrain and interiors); merge all the objects in a temporary mesh to pre-computes PRT stuff (I'm using DX functions); and is responsible to read and write results to/from a file.

Like the DX sample, I'm trying to code PRT per Vertex. This means I store the PRT data in each vertex.
I extended the GFXVertexPNTTBN to store the PRT data. At the moment, all TSMesh use this new vertex, in the future I hope to use the new vertex declaration only for PRT calculations since it uses a lot of memory.

Since I have implemented Effect support, I will use this framework to rendering the object. It's what I'm doing at this moment.

I don't have any results yet, but I hope to show something in a few days.


About the terrain, I built a mesh using the highest LOD (that's all I have done).
I have some doubts if this will work. My plan is to store the PRT data for the highest LOD and use this data to create the adaptive mesh...

I haven't look to the interiors yet.

--- edit ---
i deleted some weird characters caused by the copy&paste from word

#7 Hey David, have you had any luck with the PRT implementation? I saw it in action today in another engine and I would love to see it in TSE.