Using the parameter getters an setters and also the attach de attach

 bool GetScalarParameterValue(const FHashedMaterialParameterInfo& ParameterInfo, float& 
 OutValue, bool bOveriddenOnly = false) const override;

void SetScalarParameterValueInternal(const FMaterialParameterInfo& ParameterInfo, float Value);

What is the ParameterInfo for each of these? where do we find it and where is that at in the instance?
Why would’nt that just be the ■■■■ parameter i need as an example “DiffuseBrightness”? Why is this so complicated?

Attach, DeAttach section

 AttachToComponent(GetAMesh(), UEngineTypes::KeepRelative, SocketToLandin);

I can not get UEngineTypes::KeepRelative how do you set KeepRelative? same as the above lets over complicate ■■■■, shakes head :face_with_symbols_over_mouth:

Ok so for the attach deattach functions i defined them like so.

EAttachmentRule AttachRule;

EDetachmentRule DeAttachRule;

now i try to use them and no go

GetMesh()->AttachToComponent(GetAMesh(), AttachRule.KeepRelative, SocketToLandin);

    AttachRule.KeepRelative  AND DeAttachRule.KeepRelative 

CAUSE compile errors? How are we suppose to use these?

Bump: No one knows nothing about this?

Add the header

Then you can probably create the object, save it to a variable, and press . After it for intellisense to spit up options.

Same for engine types. Except sometimes they are included with kismet stuff. You can always force the code to know what they are by adding the header in.

Thanks for that info, i figured out the attach, de attach code.

The material stuff. I have it down to the last line the line that actually calls that parameter value change. Also trying to figure out is it better to just replace the instance with another or just edit t texture as a parameter and change it that way?

Better for what?
Game, performance, ease of use, etc. ?

For all the above. Hey after Spending yesterday on the material stuff i have a few questions that i am hoping you can answer.

In the instance itself you can not set the Scalar parameter as the functions is protected and if i use over ride the texture function it is editor only, so i got to digging a bit deeper and find an material instance dynamic that has all the functions i need and are public, but how to do make that in the editor? i can cast it to one but i can not call the parameter function as i crashes. If i cast it to a dynamic it will take but i can not run any of it function without crashing. So i figure we must have to make the instance dynamic but found no way to do this. Any ideas? or do you know the answer to the question. How to get a dynamic working to use to call the parameter functions? I see a lot of getters but no setters until the MaterialInstanceDynamic.

I will have to say after a full day going thru the material stuff. It was very interesting seeing how you guys got this all going, what a cluster of items, :grinning:

Different usage = different pathway.

Normally in just about any tutorial you make a MID (which isn’t a sound file!) A material instance dynamic, you assign it to the mesh, And you modify that dynamic instance.

This is done at runtime to access scalars and other variables (colors) at runtime via the actor that uses the mesh.

You’ll find if as the base part of almost any tutorial BP or not.

Also, material variables are usually one way - only set and no get. As there isn’t a BP method to pull out any computed values (that I know of).

The normal workaround is to “know” what the material does, and run the same equations in CPP to get a Time & LOC based answer.
Common examples of this are how to read wave heights into the CPU thread for use in gameplay.

So, without knowing a bit more about what you are hoping to accomplish it is kinda hard to give you pointers.
But chances are you need to create/consturct a new MID based on the mesh material(s) and then change the mesh materials to the MID.

ok this is what i am doing. I have a model in game as it makes its decision on what number has been chosen. I need to take that instance and save off its UTexture into an array, WHICH WORKS PERFECT.
Then i take that Texture array and the number array which work in parallel to each other. Then i run them both thru the same for at the same time, the number gets the models slot that the used texture is on and the texture will replace its used instances UTexture with the one in the array. Every thing is working perfectly except, i have not figured out how to use the dynamic part. or should i say SET the parameters with what i need.

What a pain in the a-s-s! after everything i have did. What is the use to make instances for, so i can make dynamic ones and reassign them why not just let us make dynamic materials and assign them to the model and just use them. This process sure has changed into a complete pain in the a-s-s!

You must be fairly new to unreal.

The reason behind the 2 is that instances, which you should always use:

Instances are adjusted in engine.
They then get baked down to what you set as different materials, saving you cost and computation at runtime for specific parameterized values.

Whereas, dynamic material instances work specifically at runtime to change the material on screen - which can have really high costs, depending on what you do.

The reason they can’t use the same path is essentially that.

If you are doing things in editor, before the game gets built. Then finding the right way to handle the material instance is what you need.

If you are doing things at runtime, then using the dynamic material instance is the right thing to do.
Pita as It may be.

before all we had to do was get the instance and use the parameter function on them to use them. Now we have to make a second instance which is a dynamic one, So i can set textures at runtime when i need them to. I guess i have no choice but to make a second instance to reapply to my model?

We never had to do that in udk, it was make an instance and use it. yeah, fairly new to udk > over 10 years using it. :wink:

Just to help make things more clearer. I am not using BP this has all been done in c++. I might end up using some BP capable functions, but its all done in c++.

UDK is different - I still think it was better looking at it. Never really did get to use it.

Regardless, if you want to triple check what I said (which is always good).

thanks for the info. I got it made yesterday, but it still will not change the texture or the brightness. As if the parameters are dead or just not being activated. All my logs are showing everything perfect. I logged every line just to make sure it was all acting properly and it is all ok, has got me baffled at the moment on why this is happening.

I will go read about those this morning and thanks again. Hope fully i find something i am missing. Have you got these to work or tried them or has anyone got these to work or used them. I am assuming someone has got these to work and if so and you are them how did you get them to activate the params once you have the dynamic instance made?

Just read the above pages and i already knew all that, so that will not help but it was good to read to just to make sure i did not miss something there. I need someone who has actual did this in c++ so they can point me to the proper mess up i have made or what have i not added. I copied the params over to the new dynamic instance but still nothing. Not sUre what i am missing or what the heck is going on to not change them. When logs say they should be changing.

Found the problem. After you make the dynamic material instance and copy the parameters over to it you must use SetMaterial() function to set it to the object then you can edit the params and it works great.

Thanks for all the help MostHost_LA

1 Like

Was going to suggest that.

Look into some cool tuts from when epic was still rocking.

Even if it’s BP oriented the material logic is the same.

1 Like

Yeah, if you reuse the dynamic instance like i am, you must save a copy of the dynamic instance it makes. Then next time thru you have to check if its been made and if so reuse it. If not then make a new one and save it to the existing array. If i make a new one and ones been made for that slot everything goes bad. :upside_down_face:

Basically you lose the dynamic instance you had made and new one goes on and everything goes blank.

Something also interesting i found is when i turn the brightness back down if i have more then one of the said objects in the map i must use this-> in the call so that it seems to understand that the said object made the call and then it wont effect the other objects that are in the map. Example was if I turn the brightness back down it would do it it on all of those said objects in the map, not just the one i was after, then once i use the this-> in front. Then that seemed to straighten that out.

What you are saying last would probably depend on Where the code you built was created?

And HOW you are applying it to the mesh?

Meshes are instanced.

2 of the same mesh MAY be the same instance.

There’s costs involved in “individualizing” objects.
But yes. It makes sense.
This-> likely affects only the instance.
Not using it, likely changes the mesh for all instances.

1 Like

using Setmaterial() function

Here i will just show you the code make it a bit easier.
That will do one texture on the model. If it has been made do not make it again just reuse it.

	if (this->WinningAmerNumInfo.bIsEven)
		bool EvensBeenMade = false;

		UE_LOG(LogRouletteTable, Log, TEXT("ACQ_RouletteTableAmerican::SetWinningLights() EvenDynInstName is %s"), *EvenDynInstName.ToString());
		for (int32 i = 0; i < this->ReUse_SavedDynMatInst.Num(); i++)
			UE_LOG(LogRouletteTable, Log, TEXT("ACQ_RouletteTableAmerican::SetWinningLights() *ReUse_SavedDynMatInst[i] is %s"), *this->ReUse_SavedDynMatInst[i]->GetName());
			if (*this->ReUse_SavedDynMatInst[i]->GetName() == EvenDynInstName)
				this->ReUse_SavedDynMatInst[i]->SetScalarParameterValue(BrightnessParam, 5.0f);
				EvensBeenMade = true;

		if (!EvensBeenMade)
			//lihght even area on table
			int32 EvensIndex = this->GetAmericanMesh()->GetMaterialIndex(EvensSlotName);
			UMaterialInterface*	EvenTextureToDisplay = this->GetAmericanMesh()->GetMaterial(EvensIndex);
			UMaterialInstance* EvenInst = Cast<UMaterialInstance>(EvenTextureToDisplay);

			UMaterialInstanceDynamic* EvenDynInst = Cast<UMaterialInstanceDynamic>(EvenInst)->Create(EvenTextureToDisplay, this, EvenDynInstName);
			UE_LOG(LogRouletteTable, Log, TEXT("ACQ_RouletteTableAmerican::SetWinningLights() EvenDynInst is %s"), *EvenDynInst->GetName());
			this->GetAmericanMesh()->SetMaterial(EvensIndex, EvenDynInst);
			EvenDynInst->SetScalarParameterValue(BrightnessParam, 5.0f);
			UE_LOG(LogRouletteTable, Log, TEXT("ACQ_RouletteTableAmerican::SetWinningLights() EvenDynInst is %s"), *EvenDynInst->GetName());

Ok but where is this code?

Basically, it doesn’t seem very OOP oriented.

Create a class, give it a custom dynamic material instance variable.
Update that variable when you create the instance.
Apply that variable to that specific instance.

If you are doing it off a Manager system (which is probably way better performance wise).

Then the process needs to be the same, but you access the objects from the manager instead.

Last question.
Are you just trying to toggle a bool inside a specidic material?

The setup is nearly identical anyway.
Changing at runtime kinda requires either material parameter collections, or dynamic material instances…

all i’m am after is to brighten up the winning areas on the board then once eveyone has been paid turn them back to normal and start the new session < repeat the session. Also i am saving off the number to be displayed after they have came up on the last number rolled board. Which requires me to make and instance and set a texture to the display board and while shifting them each time a new number comes up. which i have all working.

Basically i took AActor and extended it to make a new Class called AmericanRoulette. That class will do everything the American Roulette table will do. I can just drag and drop one into my map set it up with a few vars, So it knows what table your at and all is ready to go. You walk up and at a certain distance it joins you to the table. Same distance disconnects you if you go away. You stand there playing roulette with 6 others or table max, from the net.

I tried putting in two table meshes into the same class constructor but it did not seem to want to read the config bool var on which table to make the mesh for, It was always false and it loaded the 1st mesh always, so i had to make two classes, one for American, one for European.

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.

  1. The table shouldn’t use tick.
  2. the win should be an event (you seem to have that).
  3. 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)


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. :stuck_out_tongue: