Using TRay on Meshvoxel manually possible?

[Zimond]

I am now at the part of learning how to make stuff selectable and took a closer look at the object picking example.

In order to check for MeshVoxel Intersection it seems that you can only do this by using TObjectmodels, TObjectmodelview and its "select" method. While I absolutely appreciate the simplicity of this method, I still would like to know If i can do this manually some how?

Im guessing that in order to check for intersections with a voxelmodel you will have to make a cube intersection check for every "voxel" in it, right?
So, can these be accessed somehow?

The reason for my question is: I would like to be able to build my own structures for organizing meshes, materials ect. So I can add specific stuff to it from the beginning.

[lifepower]

Selection in object models is performed by using bounding volume hierarchies (BVH), which are built automatically from the object hierarchies. For objects that have their voxel representation, the selection is further refined through octree-based search. In other words, when referring to "voxel representation" in Afterwarp, it is actually referring to voxel + octree combination. And yes, there is a function to test for intersection between ray and voxel/octree, which has very similar syntax to TRay.IntersectCubeVolume (RayIntersectCubeVolume API call), where you have to provide "world" matrix, which defines both the size, position and orientation of the object.

However, this intersection function is not yet exposed through public API, mainly because there were no requests for it yet. However, I can easily expose it in the incoming update (it is coming shortly, there are still some additions being incorporated).

[Zimond]

However, this intersection function is not yet exposed through public API, mainly because there were no requests for it yet. However, I can easily expose it in the incoming update (it is coming shortly, there are still some additions being incorporated).

That would be great! I just check for bounding boxes now which, when I think about it, is nessecary anyway to pre-select objects and not waste a voxel intersection check for anything outside of the bounding boxes.

[lifepower]

Yes, in Afterwarp's framework, I've already exposed this function (so just please wait for an incoming update), in Pascal version it'll be "TMeshVoxel.Intersect". For bounding boxes you can use TRay.IntersectCubeVolume, which does Ray vs OOBB (object-oriented bounding box) testing. Internally, Afterwarp has also functions for testing intersections of rays vs AABB (axis-aligned bounding boxes). I can expose these functions if you think it'll be useful.

[Zimond]

Well, of course I had to google first what the heck these are now ^^ . I think I get it. Mmh.. no, i don't think I can currently think of anything where I would need AABB.

Another thing.


I used TVolume.BoundsToMatrixVolume which does, as it says in the helpfile, center the mesh and put it on zero plane. The banana object isnt. Thats why it's not aligned.


How can I get the bounding box without the centering? I mean, turning the bound values into a matrix is probably easy. But I couldn't find out how a volume matrix is defined.

Something like
min.x max.x 0 1
min.y max.y 0 1
min.z max.z 0 1
0 0 0 1

? (probably not, i guess ^^)

[lifepower]

The volume matrix describes a rectangular volume that has been scaled from unity sized rectangle centered at origin. So, if you have object with minimums at (-100, -200, -300) and maximums (200, 300, 400), the size of object would be (300, 500, 700), thus the volume matrix can be made as:

// Rescale unity cube (1,1,1) to proper size, then re-position it.
FMyVolume := TMatrix4f.Scale(300.0, 500.0, 700.0) * TMatrix4f.Translate(50.0, 50.0, 50.0);

By convention, Afterwarp's object model system assumes that each object's origin is on bottom, so it is convenient placing them on surfaces like a floor; thus, functions inside TVolume are mostly useful for meshes loaded from external files to calculate such volume. However, Afterwarp's object model system can also work with any other convention and normally object models calculate their volumes automatically; so when working with your own code, you would probably use the aforementioned approach to specify the volume manually.

[Zimond]

As soon as I got to bed a solution came to my mind. Translate the box back by the midpoints of the minbounds and maxbounds values.
Or even better, I correct (center) the mesh position itself because you are right. Leveling objects makes sense. This way the obj files dont have to be changed.

[Zimond]

Yaay, I can center loaded objects now. Just one thing.

I applied the correction translation now in the world matrix during rendering.
I tried doing that with the Meshbuffer right when loading the mesh (So the correction is "baked" into the Meshmodel and doesnt have to be applied at every render instance) but it seems that TMeshbuffer.transform doesnt affect loading meshes from file, only creating meshes. I assume it has to be reset before loading an obj file? No big deal though.

PS : You might think "Why not just make sure that my obj files are centered and alignted?" Which is right, but since my far far away goal is to make another game editor for people to use, I can foresee that people keep asking why their object is always half within the floor when they add it.

[lifepower]

When generating mesh at run-time using existing primitives in TMeshBuffer, TMeshBuffer.Transform is applied during generation of vertices. However, if the mesh has been loaded from external file, you have to call TMeshBuffer.TransformVertices to explicitly transform the vertices.

Although it's matter of conventions and/or personal preference, I would put the transformation that centers the mesh into the world matrix, instead of pre-processing vertices. In practice, there could be many situations where you would need to do adjustments either to the original mesh, or the matrices themselves, so I think it would be a generally better practice not to make any assumptions about mesh position and/or orientation within its local coordinates.