Modify vertices after object creation?

[kwagner]

Is there a way to modify the vertices of an object after it is created? Like an X_SETFACE command or something. I have a series of quads that I want to stretch and twist each frame, and the only way that I can see to do it is to create new objects each frame. If I'm missing something obvious please let me know

[kanonet]

Pure standard GLBasic cant do this. Ideas to get it working:

• if its only a few manipulations that happens again and again, maybe you can precalculate them?
• recreate the object each frame (can be slow)
• draw directly in native OpenGL (I would suggest to use glDrawArray), so you can easily change it every frame
• draw the object with GLBasic and manipulate it in a shader (you would need to write your own glsl shader, and it would run on desktop platforms only)

[kwagner]

Thanks for the info. Not to sound completely ignorant, but is there a reason it can't be done (I don't know much about the internals of OpenGL so maybe it has to do with where objects get stored or put in the pipeline)?

I was looking to fiddle around with a polygonal pseudo-3d road like this: http://www.extentofthejam.com/pseudo/#proj3d as I've already created a few non-polygon rasterized versions.

[kwagner]

I was thinking, maybe in this case where I'm basically skewing in one or two directions (left/right for curves, and up/down for hills) i might be able to get away with using x_multmatrix per segment to accomplish the skewing. I'll try a few things.

[kanonet]

There is simply no GLBasic command to change an object. I guess its because of the specially effects that GLBasic can do with objects (animations, shadows etc.) in order to speed them up at runtime, it precalculates things at loading - so if you would alter the objects you would need to recalculate those things. So maybe its easier to simply recreate the object, instead of writing a command that allows to alter an object - and maybe there simply wasnt a real need for such a command before.

[kwagner]

Fair enough. I did have some success with using matrix multiplications to skew segments, but the math to get a whole level working is more than my brain can handle right now I'll give object creation a try next to see performance.

[matchy]

To experiment and speed test, use no X_OBJ commands. That is, store the mesh in an array, change the vertices and then X_LINE wire-frame plot it.

[kwagner]

At first I had a separate object for each road segment, and edited them each time of the game loop. That worked decently for a while, but as I added more segments for sides of the road, I started hitting odd performance issues. It seemed some internal garbage collection or something was causing issues. I also hit some non-debug-catching access violations if I added too many objects. I then decided to try pre-rendering segments of -30 to 30, but found it too limiting for the smoothness that is a hallmark of the pseudo3d road. Finally, I went back to the original method, but created one object for the whole road strip. This had good performance and scaled well to allow me to make the grass on the sides as well. Attached is a pic of the result. Thanks for the help

[matchy]

That's very cool and you didn't need to modify the object. 

It's something I'd like to do but with real-time tiling (but like with my RR and MK demos), where the object needs to prepared such as as splicing an existing landscape. I wonder if one object with, for example, 10000 vertices is better than 10 object with 1000 vertices. 

So how many vertices in that single road object? 

[kwagner]

For my testing at least, 1 object with 1000 verts is better than 100 objects with 10 verts. Your mileage may vary

I let the size of the road segments be user-selectable at runtime for the test. In the above pic, each segment was 20 'lines' worth, and it's showing 1000 lines, so 4 verts * 50 strips * 5 columns (2 for the sides, 2 for the grass, one for the road) = 1000 total.
Good performance on my super-low-end laptop. Performance definitely favors the static meshes, as each of the cars shown have more than that and I have 500 of them spread out on the road (probably 50 or so in any given shot). Creating one giant mesh of all the strips together might perform even better, but I wanted to give them separate textures and it seemed the easiest way without messing with a supertexture and worrying about the coordinates on the vertices.

On my higher end desktop, I can go to 10 lines per segment and still see better performance than my laptop, however lower numbers after that start suffering. I'd assume a cpu bottleneck rather than the gpu, but I'd have to do more tests. Full screen vs windowed didn't seem to have an affect on framerate.

[matchy]

The viewing distance is the main design issue. 

How about going down cpu and test on an Android device? 

[erico]

That road looks great. Can you post a video of it in action? I´d love to see the resulting movement on this.

[kwagner]

I might do that later on, I had some issues with my android emulator and don't want to get too sidetracked right now

I'd be happy to post a vid of it in action. I'll do a couple runs at different segment sizes so you can see how it affects smoothness.

[erico]

While at that...why not get inspired by some great tracks that I guess do fit perfectly!
http://lazerhawk.bandcamp.com/album/redline

Cheers!

[Kitty Hello]

Use the same object and rebuild it with X_objaddvertex.... The memory is kept internally. Use manual normals and x_objaddnormal instead.

Gesendet von meinem GT-N7100 mit Tapatalk