Ok. I know jack about how a roulette table works, but
Are there supposed to be many tables in the game room?
How important is performance (what’s the target system?)
The likely easiest approach here is to make each square it’s own thing.
It’s literally just 2 tris per square.
how many possible draw-calls can that be when looking at the table? 100?
Can it be packed down and optimized - ofc.
Single texture, mapped to each face. Update the texture. then it’s like 3 draw-calls.
can we make that even better? maybe use an INT to define the lighting parts?
If you build the UV specifically for it, yes.
(and because it’s on the GPU, the calcs are faster than using a texture update).
Now on the Code side of things.
- The table shouldn’t use tick.
- the win should be an event (you seem to have that).
- I’d use a timer function to fade in/out the material effect. You can do this in C++, but why? It’s kinda way faster to do in BP due to the timer’s visual interface and the ability to add variables to the timer.
Each table needs it’s own material instance - instanced to the mesh (probably only the play area slot you know, save up on processing by splitting into multiple slots and having the outer be the same).
In the extended class, add a dynamic material instance variable as a pointer.
UMaterialInstanceDynamic* midTableGameArea
then initialize it on construction.
midTableGameArea = cast etc. (you don’t have to save off the slot, either, you can just pipe it in)
Cast<UMaterialInstanceDynamic>(EvenInst)->Create(
this->GetAmericanMesh()->GetMaterial(
this->GetAmericanMesh()->GetMaterialIndex(EvensSlotName)
)
There’s better combos of that probably - doubt you need to go find the index to feed to the function. Look into that.
Then assign the material
this->GetAmericanMesh()->SetMaterial(index, midTableGameArea );
Once that’s done Once on either construction or Begin Play (depending on what else is needed to initialize it?)
you can just manipulate the instance directly from anywhere in code.
Assuming that you “properly” defined the midTableGameArea as public.
Saying “properly” because arguably it should be private, and you would need to create wrapper functions to toggle it that access the variable and manipulate it.
Regardless however.
Because this is happening on construction or begin play any instance you bring into existence is automatically assigned it’s own custom MID instance.
So multiple tables will be affected differently.
Make sense?
I’d suggest figuring out how to split up the UV to color up the proper cells with just an int.
That way if you hit 36, you color in 36, and unless math is an opinion you also color even.
Not sure what else needs to be colored in though. As I said don’t know much about roulette unless it’s Russian… Unreal is pretty much that. Russian Roulette. 