Color of mesh texture hit by ray

**Esenthel** · 05-19-2014 01:15 AM

Quote:face/triangle index (phys_hit.face) getting from physical hit seems not the original mesh face but the one for physical check.

Thank you for reporting the issue, for next release I'll add an option to preserve the original face indexes, via adjusted PhysPart methods:

Code:

Bool      createMeshTry(MeshBase &mshb, Bool keep_face_indexes=false); // create as static mesh, 'keep_face_indexes'=if preserve original face indexes in the 'PhysHit.face' (when enabled this will use additional memory, when disabled the face index will point to the internal face of the physical body but not the original face of the source mesh), false on fail

   Bool      createMeshTry(MeshLod  &mshl, Bool keep_face_indexes=false); // create as static mesh, 'keep_face_indexes'=if preserve original face indexes in the 'PhysHit.face' (when enabled this will use additional memory, when disabled the face index will point to the internal face of the physical body but not the original face of the source mesh), false on fail

   PhysPart& createMesh   (MeshBase &mshb, Bool keep_face_indexes=false); // create as static mesh, 'keep_face_indexes'=if preserve original face indexes in the 'PhysHit.face' (when enabled this will use additional memory, when disabled the face index will point to the internal face of the physical body but not the original face of the source mesh), Exit  on fail

   PhysPart& createMesh   (MeshLod  &mshl, Bool keep_face_indexes=false); // create as static mesh, 'keep_face_indexes'=if preserve original face indexes in the 'PhysHit.face' (when enabled this will use additional memory, when disabled the face index will point to the internal face of the physical body but not the original face of the source mesh), Exit  on fail

However since you have just a sphere, you don't really need the face index, because you can calculate correct coordinates based on the collision position and the sphere center.
Vec delta=phys_hit.plane.pos - ball.pos;
delta.normalize(); // use this further

Biga · 05-19-2014 10:29 AM

(05-18-2014 11:10 PM)Rubeus Wrote: You can create a physBody.part from a static mesh. You might be able do that, feeding it your object's mesh. I don't know for sure that this will work, but it might be worth a try.
Otherwise, you could just do the calculations yourself instead of via the physics engine.

yeah it is done that way, but the vertices are different of physbody part and the original static mesh.

Code:

MeshPtr Meh = Earth.mesh;

  PhysBody Body;

  PhysPart Part;

  Part.createMesh( Meh->setBase() );

  Body.parts.add(Part);

(05-19-2014 01:15 AM)Esenthel Wrote: Thank you for reporting the issue, for next release I'll add an option to preserve the original face indexes, via adjusted PhysPart methods:

thanks, that would be awesome smile

Biga · 05-20-2014 11:13 AM

other solution we tried that render province map to render texture with custom render target (dest_rt) and getting color from that image on hit.

1st material is main map to show on mesh, 2nd material is province map which we render to texture (and doesnt show on sphere).

first problem that it is very slow (changing the material to 2nd for render to texture, then changing back to main texture for rendering the view, drops to 1-2 FPS), second problem that the color() of render target image returns 0 for all x,y coordinates. we show the render texture image so that created and rendered properly..

Rubeus · 05-20-2014 06:24 PM

Remember, if you render any image (texture, render target image, etc), you need to lock it or it will always return 0.
If no one ever sees that second texture, make it lower res, then use
MaterialLock = lowrestexture;
<render to texture>
MaterialLock = NULL;
and it should speed things up. You could also use a lower res render target image.
If you want to go that route, that is.

**Esenthel** · 05-20-2014 09:40 PM

Image.lockRead before reading pixels/colors and 'unlock' after, but for render target that's still slow.

The fastest way to read pixels from texture that doesn't change, is to copy it to 2nd Image of IMAGE_SOFT mode at app startup. and read from that (then you don't need locking).

You can calculate the UV from the "Vec dir" that I've showed you in my last post.

yaw =Angle(dir.zx());
pitch=-Asin (dir.y );
you may need to check the signs, and adjust the scale from PI to 1 (or something similar)

Biga · 05-21-2014 10:09 AM

thanks.
there is another problem with reading render target, that seems it cant be used for color RGB-province mapping, because colors are changing while rendering-antialising+ maybe due to light and other rendering effects. even if I find the correct x,y on my color map, the original color of image is different what I see on the rendered target image...

Nikon · 05-21-2014 10:44 AM

Hi Esenthel,

The mesh was manually detailed using a modelling app, so the rectangular texture we are using doesn't follow any specific pattern of UV map (stretched around, icosahedronic map, etc.) So our only solution here would be.

. Use raycasting which you have at very efficient performance from what I can tell at this time, if we can make sure the face indexes of the physical mesh match the original triangle mesh then we have our issue solved as we can get the UVs from there and match the offset between click and triangle vertexes to get the perfect click UV.
. Render to offscreen texture, disable all types of antialiasing and similar to avoid blended colors, make sure that all colors are rendered as like the original texture.

Currently the second one is working, its the "default" way of handling click anyway, but I'm having trouble (probably out of ignorance) in making sure that the drawn material colors are exactly like the original image, can you explain to me how to disable everything that might interfere with it? (AA, Lights, etc..)

Also, are engine updates scheduled at specific intervals of time or do you upload them when you feel that you have enough to make it worth?

Best Regards,
Nikon

**Esenthel** · 05-22-2014 01:00 AM

Quote:can you explain to me how to disable everything that might interfere with it? (AA, Lights, etc..)

Please look into D.ambientPower(1); disable all other lighting, disable bloom (D.bloom*), possibly disable fog/sky/clouds if you're using it. Unless you're using anything else, that should be it.

The first method will be much more efficient (with the phys triangle hit).

Quote:Also, are engine updates scheduled at specific intervals of time or do you upload them when you feel that you have enough to make it worth?

I usually release new updates when there's enough new features gathered to make it worth like you say, and also I try to make at least one update per month.
You can see my past release schedule here:
http://www.esenthel.com/community/forumd....php?fid=8

Usually I update just the source more often, and the binaries less frequently. Because just updating the source is much faster for me (takes only several seconds, while binary for all platforms takes more than an hour).

Biga · 05-22-2014 11:08 AM

Im afraid antialiasing cant be switch off in EE, can you confirm it?
As it is a province map, antialiasing results that we cant identify provinces especially if player clicks to near borders where neighbour colors changed due to AA.

Zervox · 05-22-2014 11:31 AM

D.edgeSoftenMode(EDGE_SOFTEN_NONE);

Biga · 05-22-2014 11:57 AM

mhm that I tried... but I see still AA on render target... but maybe I missed some light yet.

PHP Code:

float ap = D.ambientPower();
      D.ambientPower(1);
      EDGE_SOFTEN_MODE esm = D.edgeSoftenMode();
      D.edgeSoftenMode(EDGE_SOFTEN_NONE);
      Sky.clear();
      
      Renderer.allow_bloom = false;
      Renderer.allow_glow = false;
      Renderer.use_hdr = false;
      
      Renderer.dest_rt=&rtt;                                                // specify custom render target
      Renderer( SphericalWorld::Render );                                 // perform rendering
      Renderer.dest_rt=NULL;                        // disable custom render target
      Renderer.allow_bloom = true;                                              
      Renderer.allow_glow = true;
      Renderer.use_hdr = true;
      Renderer.type(rt);
      
      D.ambientPower(ap);
      Sky.atmospheric();
      D.maxLights(1);
      D.edgeSoftenMode(esm); 

maybe D. methods only for display drawing?
seems doesnt affect render target

Rubeus · 05-22-2014 03:29 PM

Is it possible your graphics drivers are applying their own AA settings to the rtt image? This would make the rtt approach unfeasible.

Also, what resolution are you using for your rtt image? If it's not a power of 2, maybe that effect is caused by resizing.

Biga · 05-22-2014 08:21 PM

we tried 256 and 512 ones.
well seems really the best to wait the mesh face index addition to engine and finish that way.

**Esenthel** · 05-24-2014 09:35 PM

Hi,

I've just committed a source update that include preserving the phys mesh face indexes.

As for the blurring: you probably need to set the same Render Target resolution as the current screen resolution. But still the phys triangle indexes will be the best way.

Biga · 05-27-2014 12:08 PM

Hello Esenthel,

thank you for the addition, it works fine!
we get the proper provinces with the code using face triangles, and with keep parameter we get the correct one.

if someone will encounter with the same problem, post #12 will be useful, and it is necessary then to create the mesh with the new parameter:

PHP Code:

PhysPart Part;
      Part.createMesh(Earth.mesh->setBase(), true);  // true for keeping original face index
      Body.parts.add(Part);
.... 

Color of mesh texture hit by ray
Author	Message