Horde3D

Hmm,

I'm having a funny issue here, so I thought I'd share it for everyone. I'm doing some picking code for my game (for those of you who dont know what picking is, its casting a ray out through the cursor on screen into the 3d world and telling you what it hit). My game is sort of 3D lemmings meets a twisted version of the sims, on acid.

So I'm working on the picking code, that all seems to work fine.

So I go onto "creating" that is, populating the world by being able to click on the level and create an object at that point. Anyway, I have a mesh which I create at the intersection point where my pick ray intersects the level. Only I'm noticing weird behavior, because the create cursor (a mesh only object which represents the eventual object I'll create) starts moving towards me!

So It eventually dawns on me that what is happening, is that the pick ray is intersecting the mesh node for the create object. Essentially the create cursor is hitting itself and slightly offsetting itself each time it gets intersected. So I add code that basically ignores the intersection if the node being hit is the cursor node. Only this doesnt work either. I already had the current node under the pick ray displayed so I could debug the picking and weirdly it showed me a different node number than the create cursor.

It had me stumped for a while, trying to imagine where this node was coming from. Then it struck me. When you add a scene resource to the scene, you arent only adding a single node are you! You load up a scene file, which might contain multiple meshes. Each one of which might have a node!

So there's the issue I think. That a character model in a scene isnt actually a single node, but a collection of them. So when you add a scene resource to the scene, the node handle you get back is just the topmost node handle and the pickray can return any one of the subnode handles.

I can thnk of a few ways to fix this, but I'd like to hear what you guys think before I jump in and fix it.

It's better to change the pick node function behavior. It was a little confusing for me too in first steps, but it isn't a big problem at all

Currently we should store the child node handles somewhere else then compare them with the returned node handle and move the parent node, because child nodes origin/position differs from the parent.

EDIT - Possible solutions :

#1 | Adding another argument to the pick node function to tell that what kind of resource type node handle it should return [ model/mesh or parent/child ]

#2 | Adding another argument to the pick node function to tell that in which parent node it should start searching. If returned node handle was a child of the parent model, it should return the true.

If you add a scene file you are indeed adding several nodes. If the scene file consists of a model, you are adding all (sub)meshes of this model as a separate node. If you doing a hittest on your scene you should get the mesh node that was hit by the intersection ray. If you want the model containing this mesh, you have to call h3dGetNodeParent until you will reach the model node.

But I didn't understood what you mean with


Why it is moving if you only do a hittest?

The other problem of having a hittest with the cursor itself may be possible to solve by enumerating the intersections using h3dGetCastRayResult. This way you should get the object mesh you are interested in too, shouldn't you?

Its moving because I'm placing the 3D cursor (I call it the create cursor) at the intersection point. The idea is that you will have a semi-transparent version of the mesh you will be placing as a "ghost" on the level, until you click the left mouse button to actually create it at that point.

But because it is self intersecting, the intersection point is slightly offset from the mesh origin and therefore it moves towards the cursor.

I've fixed the self-intersection by iterating up the node chain and seeing if the node chain ever matches my node handle for the charactes scene node. But it does feel less than optimal. Plus it still actually intersects that node, which means that the mesh jumps around as its intersecting either the level, or itselft.

There are two things I can think of:

Add a list of node subtrees to ignore during the intersection tests.
Add some form of node mask for the intersections such that different tests can use different masks (i.e. all characters in the level, the level itself, all placable buildings etc).

I'll think about it some more.

The h3dutPickNode function uses h3dCastRay to do the picking. h3dCastRay creates a list of intersected nodes and you can iterate over that list with h3dGetCastRayResult. So it is very easy to modify h3dutPickNode so that it ignores some specific nodes.

h3dutPickNode is a utility function that is layered on top of the horde core API. All utility functions are just sample implementations of horde-related game engine functionality and are just provided for convenience. Feel free to make your own implementation that fits your needs based on the h3dut code. The utility functions are really just meant as a reference and to make it easier for small projects

h3dCastRay always returns mesh handles. As Volker says, you can get the model by walking up the node hierarchy. However, as alreday mentioned, we have plans to make models a single scene node and no longer a scene graph branch. Then the picking function would work more as you expected it to work.

Current picking function is suitable for FPS games [ accessing the model parts : "Head shot" ]. How would the new picking function work in future releases? Should it handled with a group of models instead of mesh?

The current raycasting function is mainly provided for convenience, for example to make it easy to do picking without having to use an additional library. If you need more advanced intersection logic in a game, it is better to use a physics engine which is optimized for that.