I can .createPlane(9,9), however, when I attempt to modify the position of a vertex like so: .vtx.pos[1] = Vec(2,2,3); I get a "function call missing argument" build error. The following works: part.base.vtx.pos(3).z = 2; (using parentheses instead of square brackets around the vertex index), however, the z scalar of the vertex appears to have moved in the x direction and not as I expected in the z direction but.

I found two threads that helped me get this far, but appreciate any help on how to properly use .vtx.pos[1] = .

Also, is there a tutorial perhaps I missed that goes over how to use some of the MeshPart base. functions?

Any help appreciated.

EDIT: I worked out how to move vertexes using (for example) .base.vtx.pos(0).z -=1, but I only got it to work on initialization. When I try that function in Render (to animate it), the vertex appears to remain static. I traced the parameter(.base.vtx.pos(0).z), and it is indeed changing value, yet no movement!

Sounds like your changing the software mesh, and drawing the hardware mesh, yet expecting to see changes on the hardware mesh: Only GPU can change a hardware mesh (it only reads information from the CPU like the skeleton positions to modify the vertexes efficiently). Modifying vertices in software is slow, and not recommended unless you're doing stuff like making a modelling tool. You need a basic license to write vertex shaders and do this efficiently.

In you're render, try drawing both meshes:

Mesh body;

switch(Renderer()) {
case RM_PREPARE :
body.draw(cskel); // draw hardware mesh
break;
case RM_SOLID :
body.parts(0).base.drawAuto(NULL); // draw software mesh
break;

e.g. comment out one at a time.

Without a license, you can update the software mesh vertex positions like this (put code in update loop):

if (Kb.bp(KB_ENTER)) FREP(body.parts(0).base.vtxs()) body.parts(0).base.vtx.pos(i) += body.parts(0).base.vtx.nrm(i) * 1e-2F;

This'll make the mesh fatter

Having said that, it's NOT recommended.

Thanks, Chris. The case RM_SOLID: function did the trick, and now it works (although I now have two copies of the mesh, one static and the other with vertexes changing).

I do respect that you say the workaround you kindly offered is not recommended, and I am thinking of buying an Esenthel license.

I'm migrating from another game engine which I don't think separated hardware and software rendering, but I knew how to get the job done for what I needed, which is making pseudo-NURBs out of regular meshes. I guessed that the way I was going about it was not efficient. I've wondered if I could use bones to do the job (software) and let the GPU work out individual vertex modification...

My game does rely on changing the shape of various objects (i.e. pseudo-NURB). To be specific, a feature of my game is to adjust the surfaces of objects (much like game terrain editors or "magnets" do to make hills and mountains, so that feature is like modeling). But unlike an editor, the volume of each object in my game always remains static. i.e. if a player's hand pulls up one part of an object's mesh, then other parts of the surface sink so that the object's total volume remains static.

I mention this because I am not yet able (being without a license) to even run the shader tutorials, but as you've seen them, do you think that the custom shader functionality that comes with a license may help me find a more efficient way to do vertex manipulation dynamically?

Accurate volume constraints in mesh deformation are rather difficult; have you done this much before, or is just an idea? Traditionally you need to solve a sparse linear system, to minimize a energy function on some matrix representation (e.g. laplace operator) of mesh vertices (kinda slow). You'll need a sparse matrix library to do this & good maths background.

Alternatively you could try faking it, but results might not be so accurate. You can scale bones, which may give you something of a bulge - but you'd need to position and rig the bones to the mesh. To constrain volume, you'd have to add extra blend-bones which reduce in scale in other places on the mesh... I'm not sure how that'd work.

You could try displacing the mesh using an image, and having negative displacement on the low frequencies and positive displacement on high pixel frequencies. You may need some local curviture quality factor or something on the mesh to fake the volume preservation.. i'm not sure if it'd be enough though, and not very robust.

Although you can't yet compile it, you can look in:

Tutorials\Source\Advanced\3 - Mesh, Shaders\Shaders\04 Shaders With Skinning.cpp
and the GPU code:
EsenthelEngineSDK\Data\Shader\Skinning.cpp - this is the kind of thing you'll be modifying if you get a license and do it on the GPU. When compiled, it shows a walking man. The CPU modifies the bone positions, and the GPU reads the bone matrix and repositions the vertices according to their (pre-computed) skinning data.

e.g. if you wanted to displace using an image, you could send an image to the GPU (see Shader With Parameter), read this on the vertex shader and displace it from the pixel intensity, respective to the position defined by the vertex texture coordinate.

Thanks for the considered response, Chris.

Yes, I have it working but using a less sophisticated engine, so not just an idea.

I more or less use a mix of the first and second methods you discuss, although I don't use bones but should as it may improve the speed and "organic" feel of the deformation during gameplay. I hadn't tried image displacement and thanks for taking the time to outline that.

As I migrate to Esenthel, my goal is to have a persistent environment as a base for MMORPG. Although I have a microscopic budget (just me doing the work), I'm trying to plan ahead by having the smallest possible data sets moving between client and server, and have efficient - low cpu cycle - functions doing the work.

To answer your question about real or faking: for efficiency reasons, and also given my mid-level C++ programming skills, the interface parts of my current implementation are real; the rendered parts fake.

To keep me focused on achieving MMORPG, I currently run a lash-up environment with Esenthel working sub-optimally in /MDd runtime (instead of /MT recommended by Esenthel) which required me to include additional lib dependencies and dlls so it doesn't crash. I require /MDd runtime so I can concurrently use Boost libraries and a C-API client to connect to a MySql database where I have mocked up a limited degree of MMORPG functionality for testing.

Hi,

I think I roughly understand your framework in my head now, it sounds interesting, especially that you're willing to go through a lot of work to get something unique

Was gonna comment on "constraining vertex movement to y-scalar" & summed pseudo-height total = const, thinking that this process is sensitive to the vertex density/distribution - but I guess your "joint probability density functions" get rid of that problem. But yeah, I think you should try to get it working in software first using you're existing method, then think of ideas for optimizing it on the GPU. There's a lot of things you can try; I guess you're bottlekneck will be your solver & user inputs. Bones have the disadvantage of needing to be placed and orientated, and the rigging problem, whereas the image has the disadvantage of it needing to be modified on the CPU/slow diffusion functions etc - but maybe you could send other kinds of meta-structure to the GPU. I guess it depends on the types of meshes you're deforming, and whatever constraints you have (e.g. if you additionally have hierarchy).