Obtaining viewpoint information from inside a scene node

Promit · Post by **Promit** » Wed Jul 21, 2004 9:54 pm

I need to get information about the camera viewpoint while rendering in order to do LoD calculations. Specifically, I need the position of the camera.

It would also be extremely good if I could get the position of the near clip plane and the vertical resolution in pixels.

(This is for an experimental geomipmapping implementation. The code comes from my own code base, and I'm attempting to adapt it to Irrlicht.)

Asterisk Man · Post by **Asterisk Man** » Thu Jul 22, 2004 4:04 am

try ICameraSceneNode *camera = smgr->addCameraSceneNodeFPS();

for camera position: camera->getPosition();

for view frustum: camera->getViewFrustum();

in the SViewFrustum class, there are a series of planes (6 of them actually), in which are the far, near, top, bottom, right and left, with which you can do view frustum culling.

what data struct are you using for the rendering?

Guest · Post by **Guest** » Thu Jul 22, 2004 5:45 pm

The problem is that I don't want to create a new camera scene node. The terrain node needs information about the current camera, and it certainly shouldn't add one. Is there any way for me to get information about the *curent* view transformation at the time of rendering?

I'm using a patch based quadtree with a single vertex buffer. The quadtree contains patches (generally sized 33x33 or 65x65, though it's flexible) and patches contain offsets into the buffer. It uses tri lists for rendering and a little trick of my own to get rid of tearing. My method reduces detail at the edges (similar to deBoer's tri fans) but does so without extra draw calls and manages to remove geometry through degnerate triangles.

Asterisk Man · Post by **Asterisk Man** » Thu Jul 22, 2004 7:18 pm

well, in a custom scene node, you always need to get the scene manager from the irrlicht device, so from there, it's just a call to smgr->getActiveCamera() and you get the camera node pointer!

Btw, im also working on a terrain rendering node, using quad trees. However, I'm currently working on implementing geometry clipmaps instead of LOD, as I'm trying to see which method takes the least time, and memory, to run, as well as which one looks best

Guest · Post by **Guest** » Thu Jul 22, 2004 8:32 pm

Well, you're free to download a (slightly old) version of the stand-alone system...

Forum thread with downloads and info

Promit · Post by **Promit** » Thu Jul 22, 2004 8:33 pm

Damnit. i suppose I should register a user name...

Asterisk Man · Post by **Asterisk Man** » Fri Jul 23, 2004 2:39 am

I saw in your demo that you change the LOD on a per patch basis, do you calculate your indices interactively, or at load time?

Promit · Post by **Promit** » Fri Jul 23, 2004 5:56 pm

I've tried both methods, and neither changes the performance. The crack fixing scheme I implemented requires you to constantly rebuild and modify an index buffer, either by using a memcpy from stored indices or calculating them on the fly. Both are fast, though I settled on the memcpy just because it's marginally faster (it doesn't have the inner loop that the index generation uses).

The system is bottlenecked almost completely in the hardware's TnL unit. On new hardware which can really push polys, the engine runs blazing fast, since there's almost no CPU work going on.

Guest · Post by **Guest** » Fri Jul 23, 2004 5:58 pm

After I work my way around Irrlicht a little bit, I'm going to rip out the core of the ITerrainSceneNode implementation and replace it with my own. The one I wrote shows its strengths mainly in the geometry processing and rendering stages -- in terms of texturing and visual detail, I haven't done too much work yet. I'll probably leave that to other people; the basic structure is extremely flexible.