Independent UV scroll per object with same mesh?

Good day

I am trying to make UV scroll work for multiple spawned objects all using the same mesh.

The problem is that all of the added objects appear to be affecting the UV in the same way, scrolling at the exact same point in time, mimicking the first added instance of that mesh (I presume that because they share the same mesh that they are all UV scrolling the same way).

Here is the (very simple) module I have made for UV scrolling:

def UVScroll(own, x):    
    mesh = own.meshes[0]
    vertexArray = mesh.getVertexArrayLength(0)
    for v in range(vertexArray):
        vert = mesh.getVertex(0, v)
        UV = vert.getUV()
        UV[0] += x

Is there any way to make the mesh of each spawned instance of an object independent of the other objects’ instances’ meshes?


Since the scrolling is done on the mesh and they all use the same mesh it looks like you cant avoid that.

Things you could try:
Add a variable to each object called offset, make it a random value on each object and try adding it to the uv position.

When spawning an object try making a copy of the mesh using something like mesh.copy() and then use replace mesh to make the object use the new mesh.

Like Josip says, you add a mesh for each frame
(for 2d sprites) on a hidden layer, with a naming scheme like
ActorJump_1, ActorJump2, etc

meshString =ActorJump_+str(Frame)
own.replaceMesh(meshString, 0)

Wow. Can you do that? I thought you have to use lib new to create new meshes.

One way of doing mesh independent uv scrolling is to use object color as a driver. There’s a couple of tutorials in the resources forum showing how to add object color to UV co ordinates using nodes.

I meant before the game ever starts smoking mirror,

plane_1= frame 1,

plane_2 = frame 2,

etc, and every instance of the sprite, is just using replace mesh targeting the object on a hidden layer.

your driver solution sounds good too, but I have noticed the node shaders seem to use quite a bit of resources right?

I’ll be taking the sprite route then. A pity, as it would save a lot of time not having to unwrap each frame.

Thanks anyways

You can make a bpy script to automate the process of separating and renaming the frames. I’ve got an example somewhere…

I would advise the shader/material option, as it offers the ability to do things like change speed, add/remove frames etc. really easily.

Example blend:
ColLookup.blend (561 KB)

It uses object colour rounded to 1/num_frames and the existing UV map to change the currently viewed frame. In the blend, press space to change on object and ctrl to change the other. They share the same mesh.

Man, it’s been a long time since I worked with sprites in the BGE, but I believe there was a way to make a unique mesh.

Hi! With libnew, it doesn’t duplicate the mesh?

yes, you just must make a unique name for the new mesh and add it,
I tried it back in the day for trying to work around my compound physics bug,
it does not make a unique physics mesh, but it does make a unique GFX mesh.

Nice file. That’s exactly what I was talking about.

Damn that’s pretty epic

That’s it, that’s what I was trying to remember. LibNew should prove useful for duplicating visual meshes.