Quote:...This would take up too much memory though, as my terrain at the highest LOD level is made up of 4096 65x65 patches.Have you considered a streaming architecture? I've had success with a crude implementation years back and am currently toying with some code to take advantage of multithreading for this. You can potentially reduce the in-memory working set down to an acceptable level whilst effectively making the landscape unbounded in size...
Quote:Original post by RobMaddisonThere is no such call unfortunately - that'd just make things far too easy [cool]
It would appear to me that my engine somehow things I'm tryin to use the fixed function pipeline. Is there a way to tell which I'm using? I'm currently using the DXUT libraries just to get things up and running. If there's a "SetDeviceToUseFVF" or something similar I can just do a search for it in my code.
I'd recommend grabbing a single-frame capture using PIX and stepping through it to the offending Draw**() call. You should be able to pull up the device state at that point in time and find out what its basing that message on.
It's common enough in complex D3D apps to think you're setting pipeline state in a certain way only to find a leaked state ruining the party. PIX will tell you exactly what state the device is in and if this isn't what you expect then you've got an application bug - you could be lucky and find that the message is due to something like this.
The flipside of course is that the state matches what you're expecting and you've either proven that your app isn't setting the correct state or you simply cant do what you're trying to do - any of the 3 outcomes being quite useful to know!
hth
Jack