Sorry your browser is not supported!

Okay so in DBP there are a set of vertexdata commands. Using the get vertexdata ptr/lock vertexdata/unlock vertexdata along with Ian Molds M1Utils plugin commands peek, poke and set maxdrawprimitives I was able to have a rolling tile terrain system that meant I could have an update-able buffer of terrain objects with shaders applied prior to manipulation to avoid state change stutters when re-applying the same shader all the while having terrains as large as I liked, only bound by ram limits. To add to that, if I was to change a mesh of an object in dbp that had a shader applied, the change of mesh would remove the shader, not only that but the other alternative was to use vs3.0 with a hmap, but the joining edges of terrain segments could not have their normals recalculated with the vs3.0 route. So I am naturally wondering what are the options here, are there agk equivalents perhaps in existing plugins buried somewhere? If not, are there methods for massive terrains? I have been through the standard documentation provided and don't see anything that jumps out. I don't expect to find replacements already in existence for Ian's wonderous M1Utils plugin, but I had noticed user Wickedx I think it was offering up his services for new commands in his own plugin(one of many great contributors to this community), but I am really not going to ask anything of him unless I have done a bit of research first or at least as is this case - ask others if they have any input on the matter?

I'm not sure there's anything you can do in real time. The meshmemblock stuff has to be "applied" to a mesh using CreateObjectFromMeshMemblock().
I guess you could do everything in a shader maybe?

CreateMemblockFromObjectMesh() along with the Get/SetMeshMemblockVertex (etc) commands

and/or

CreateObjectFromHeightMap()

Hi blink0k

thanks for the (fast) reply, I have read up a fair amount and thought those two may be the only options but don't think they are viable as they appear to be no different than DBP's memblock mesh's, the CreateObjectFromHeightMap() is basically a sped up variant to cut out all that "fathing" around as best I can tell

So far as far as shaders go, ogl appears to be very similar to direct x, now once upon a time I found that some dx shaders could have meshes switched out in DBP without reapplying the lost shader, but when I revisited it years later I could not recreate this method. it could be related to newer updates for DBP at the time, idk, I just haven't been able to reproduce it ever since.

The key to the vertexdata command set was that only when you unlocked the vertex data did the entirety of the ram held data get action-ed, ie sent to the gfx card and the peek poke commands would be used to alter the area of ram that DBP used behind the scenes prior to this, could literally choose how much work you wanted to do and when. Only when unlocking the vertexdata(ie sending to gfx card) was the performance hit the most. The maxdrawprimitives was useful for other objects rather than terrain sections as you could choose to clip however many triangles off the end of a 5k poly object thusly allowing you to reuse it for any object <5k which is useful to say the least when it comes to managing a scene. Ultimately 5k objects was my starting limit as I could easily manipulate an object of this size EVERY frame while still achieving 60fps even on some older hardware(even a LOT older than the machine I currently limp along with detailed in my sig)

Not to worry, if nobody can further the cause so to speak I will pipe up on wickedX's thread and see what his take on it is. I will revisit tomorrow anyway as its getting late here. Cheers

This guy had a terrain generator but i'm pretty sure it was c++
Here's a link to his discord post

Thanks, I had read that then saw his comment on keeping his c++ skills alive.

I have played a little with the memblock way with the 3d water shader(ripple effect) applied to a 5.4k poly sphere(built in command so tri strip I think), it turns out that the shader didn't get wiped. Was between 200 and 400 fps. Still warrants further investigation but it looks like it'll be suitable. Idk why the shader never got wiped when updating the mesh or the performance appearing ok. Time might tell I guess. Might as well forget about this thread for now at least. If I need to I'll post back, thanks for the responses though, cheers