KX_MeshProxy.meshLerp()

[BluePrintRandom]

Skin_planet_noise_ditch_working_res2_save.zip

can we accelerate this type of operation? (setting vertex pos, color and normal using a dictionary?)

vdict = { index:[pos,color,normal, uv] }

also can we save a quad polygon array somewhere during conversion? I have to run this 1 time in BF blender to get quads -> run in upbge to have re-instance physics mesh

https://www.youtube.com/watch?v=6Ntdu9E9DmA

edit: @panzergame this could drive ocean waves, pythonic shape keys, or stuff like quickly update a terrain tile. proposed api

KX_MeshProxy.meshLerp( VertexDictionary, lerpRate)

where vertexDictionary looks like

{ index:[pos,color,normal,uv] }

all vertex values are lerped by the rate (they are all vectors)

[BluePrintRandom]

just thought about it, this could animate any mesh

meshes[0].meshLerp( dicitonary, amount)

[BluePrintRandom]

DCubix why are you labeling this low priority?? do you work on upbge now?

and the ??? you don't understand it?

with meshLerp() one could make ocean waves - or python based shape keys or stuff like my tile system

[BluePrintRandom]

python equivalent of mesh lerp

def meshLerp(Mesh, M_index, VertexDictionary, rate):
    for v_index in VertexDictionary:
        data = VertexDictionary[v_index]
        vert = mesh.getVertex( M_index, vert)
        vert.XZY= vert.XYZ.lerp(data[0], rate)
        vert.color= vert.color.lerp(data[1], rate)
        vert.normal = vert.normal.lerp(data[2],rate)
        vert.UV = vert.UV.lerp(data[3],rate)

[BluePrintRandom]

this command KX_MeshProxy.meshLerp() could be based on the transformUV

https://docs.blender.org/api/blender_python_api_2_78_release/bge.types.KX_MeshProxy.html#bge.types.KX_MeshProxy.transformUV

I know it loops through the vertex and sets uv, with KX_MeshProxy.meshLerp(), we could loop through and set the Pos, Color, Normal, UV in 1 shot.

[BluePrintRandom]

https://www.youtube.com/watch?v=m2Fh4fP03ZI

[BluePrintRandom]

ok @panzergame I tried to touch base on IRC but we kinda missed each other

for a mesh with NN vertex (subdivided plane) we have get each vertex (nn) and get data from dictionary - (nn)2 and for each vertex we lerp 4 values (nn)6 I think operations.

right now I can get away with 8x8 vertex *6 or so a frame (setting and freeing)

with a compiled lerp command I think I could go 16x16 and still get 60 fps with accelerating the re-instancePhyisicsMesh command more I think we could get away with 32x32 patches.

this would be better terrain density than fallout 4 I think*

also with the patches all using the same material like this they are all batchable.

[DctrBinary]

Working on this; Does anyone know of an instance where a dict is being passed to C in the existing code base? I have some ideas but I'm wondering if there are already any helper functions written up. So far I see a lot of functions that return dicts, but none passed in.

[panzergame]

@DctrBinary : Your function should parse the argument using "O!":

PyObject *pydict;
if (!PyArg_ParseTuple(args, "O!", &PyDict_Type, &pydict)) {
   return nullptr;
}

After this you get the items with PyDict_GetItemString(pydict, name); https://docs.python.org/3.8/c-api/dict.html.

in your case i advice you to iterate over the dictionary using PyDict_Next. BL_Shader.setSourceList is taking a dictionary for example.

@BluePrintRandom, @DctrBinary : what about using a list of tuple (index, data) ?

Also data could uses a layout to specify what kind of vertex data to update:

layout = ["position", "normal", "uvs[0]"]
modifications = [(42, (new_pos, new_normal, new_uv_0)]
mesh.lerp(modifications, layout)

[DctrBinary]

Ok cool, that's what I found. Thanks for the quick reply, I'll double check that function as a point of reference.

As far as using a list of tuple, that makes more sense to me and should be faster. BPR mentioned this data structure for easy pickling.

I like the layout flags as well, that way the function only has to do the work the user tells it to. Especially since updating all of the properties could get intensive.

[BluePrintRandom]

sounds good to me, I used the dictionary to have the index of the vertex array match the index of the dictionary, but a list could do the same I suppose.

On Tue, Jun 5, 2018, 8:04 AM DctrBinary notifications@github.com wrote:

Ok cool, that's what I found. Thanks for the quick reply, I'll double check that function as a point of reference.

As far as using a list of tuple, that makes more sense to me and should be faster. BPR mentioned this data structure for easy pickling.

I like the layout flags as well, that way the function only has to do the work the user tells it to. Especially since updating all of the properties could get intensive.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/UPBGE/blender/issues/702#issuecomment-394744318, or mute the thread https://github.com/notifications/unsubscribe-auth/AG25WTQAsfN98wFTGfcwoG3ETQouOudqks5t5p4HgaJpZM4UQiJS .

[DctrBinary]

On second thought, is there any good reason not to pass in each modification field as optional args? If left out the field defaults to an empty list, no change takes place.

[DctrBinary]

Also; I'm a bit new to the source here. KX_MeshProxy doesn't exist by this name; I found the referenced example function under KX_Mesh so I've been building it there. If I've got that wrong, please let me know.

[panzergame]

@DctrBinary : Yes KX_MeshProxy was renamed KX_Mesh, all class name ending with Proxy are data created while accessing them in python, for example KX_VertexProxy the vertex object is created only at access and destructed just after. For mesh it was the same case but as a lot of access could be made to a mesh and it can be interesting to keep the python object, also as RAS_Mesh now as a KX_Mesh subclass for storing the KX_Scene, the game objects are storing pointer to KX_Mesh and not RAS_Mesh as before and so could benefit of having a class with python infrastructure.

[DctrBinary]

Oh ok, that makes a lot of sense.

[BluePrintRandom]

@DctrBinary any word? (thank you for your help so far!)

[DctrBinary]

I've poked at it a bit but I haven't had much time. This is also the first time I've done any Python-C++ linking, so I've run into a lot of gotchas.

[BluePrintRandom]

it's ok, I am just glad you have been looking into it.

Thank you again for all your efforts!

On Jul 1, 2018 2:38 PM, "DctrBinary" notifications@github.com wrote:

I've poked at it a bit but I haven't had much time. This is also the first time I've done any Python-C++ linking, so I've run into a lot of gotchas.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/UPBGE/blender/issues/702#issuecomment-401635051, or mute the thread https://github.com/notifications/unsubscribe-auth/AG25WbI0irRRPKcM0yVgA7iBK2LqFw79ks5uCUFbgaJpZM4UQiJS .