zsort around decilined plane

[lumirion]

In Irrlicht is there a way on the fly to split a sloping plane mesh so that other meshes arn't dumped either to the front or back of it if it passes through them? I have a model (not mine) with such a mesh representing light rays passing over a mountain rendered on a vertical plane with an alphablended wall mesh in front of it. The mountains keep rendering in front of the wall. I have two such light ray meshes in this model the closest one begins where the other ended and ends at a hill in the forground but my render corrupts with the sky box bleeding through. So I disabled zwrite on my alphablend function and the foreground hill dissapears, the skybox stops showing through, and the mountains moved in front of the wall. The model loads perfectly in its native engine.

[REDDemon]

you problably need to set the correct render pass. light rays should be rendered in transparent render passes irrlicht already have materials for that. If the mesh is just 1 mesh you have to Z sort triangle (not possible for all mesh since certain triangles are overlapping in strange ways..) try that.

[lumirion]

my material for the light rays is a EMT_ONETEXTURE_blend so they should be in the transparent renderpass. Does Irrlicht have a triangle sorting function? or one to break big triangles into smaller ones? I thought I read somewhere that bsp sorting selectively brakes up triangles and sorts them but is slow and out dated. I alo heard octrees are faster. Do we have those in Irrlict? If we do where can I find out how to use them?

[REDDemon]

irrlicht already sorts scene nodes. you can decide to implement a custom octree for sorting your stuff (sort groups of triangles instead of single triangles can be much faster, but can also lead to visual artifacts) or maybe you can decide that is more viable sorting directly all triangles (if there are not to much triangles). Irrlicht arrays (irr::core::array) already have sorting capabilities, you have "just" to compute the distance from the camera at every frame. try both quicksort and heapsort for sorting. Until you try them you never know wich is faster. (theorically heapsort should be faster because is O(n*logn) vs O(n^2). in practice quicksort is faster in most cases).

Also avoid to use a separate scene node for each triangle.

[lumirion]

thankyou for the advice that gives me a lot more thoughts to work with.

also I have a screenshots from a couple angles



[EDIT] Also what is the name of the array the triangles are stored in? Is it the vertex array?

[REDDemon]

both vertex and index arrays. without indices vertices is just acloud of points.

[lumirion]

k I will study the triangle selector code as I saw that it uses both arrays.

Since this is a single model file containing both solids and transparents will I need to parse the indices and vertexs by what submeshes contain them and then reorder by submesh id? Or am i just divideing the arrays into blocks by corelating 3 indices elements with their 3 vertex elements and sorting the blocks by vertex z values?

[hendu]

You're trying it the hard way, why not just separate the transparent parts to a different mesh?

[lumirion]

Im trying to implement a coustom loader for .m2 So I want to make a fix that will work for any model of this type incase there are other models with this problem.

It would also probably be posible to use the render triangle list function from device but I havent looked into that yet.

[REDDemon]

would be nice to patch your loader to irrlicht also

[lumirion]

Currently it is called through pseuwows memorydataholder so there might need to be some modification to call it directly form Irrilicht. It's not finished but if anyone wants to see it, it is in https://github.com/shlainn/pseuwow/tree ... lient/GUI/ Im also not shure if I got the blend functions perfect since I was trying to recreate them by parsing functions for gl blending.