possibility to let materials spin

[Isaac]

You should use world rotation (setWorldRotationAngles) instead of facing.

Even better, but are you sure it does not use the same thing under the hood? Though the Facing method also works with LoG1, unlike setWorldRotationAngles. Also, you have to change the increment from 0.02%4 to 1%360

[THOM]

I start to understand, but some things are still uncertain:

In your egsample, Isaac, "spinner" ist the ID, yes? i.e. "altar_1"

But what is "anim_1"?

And BTW is ist possible to call/replace a material of a model, that consists of more than one material?
In an objectdefinition you can use "material = "xyz"", but what, if you want to exchange just one of two materials in use? Or if you want to spin it in this case here.

[Isaac]

I start to understand, but some things are still uncertain:

In your egsample, Isaac, "spinner" ist the ID, yes? i.e. "altar_1"

But what is "anim_1"?

And BTW is ist possible to call/replace a material of a model, that consists of more than one material?
In an objectdefinition you can use "material = "xyz"", but what, if you want to exchange just one of two materials in use? Or if you want to spin it in this case here.

Spinner is the id yes ~it can be anything, as long as it's consistent throughout. The script name I was using is anim_1. I have used multi-material models, but Petri discourages it IRRC. You should be able to define it initially, and not need worry if the built in material swap function supports more than one material. I have not tried it myself, but I bet it doesn't.

I don't really know the specifics of what you are attempting, but here is an example:


*The gif is choppy for size constraint, but the effect in the game doesn't have to be.

If you use this instead of a Blender animation, then I would highly recommend stopping the timer when the party leaves sight of the effect.

Code: Select all

-- Animation script, called by a timer to update position.


-- I used the castle_floor_01, scaled up via GMT; with texture assigned in the model; renamed to castle_floor_02.

spinner:setPosition(spinner.x, spinner.y,0,-0.19,1)


--spinner.model:setMaterial("vortex") -----------Optional if not specified in the model file.
x = 0


function ersatzAnimator()
	x=x-1%360
	spinner:setWorldRotationAngles(0, x, 0)
end

Code: Select all

defineObject{
	name = "castle_floor_02",
	baseObject = "base_floor",
	components = {
		{
			class = "Model",
			model = "mod_assets/models/env/vortex.fbx",
			staticShadow = true,
		},
		{
			class = "Occluder",
			model = "mod_assets/models/env/vortex.fbx",
		},
		
		{
			class = "Platform"
		},
		
		
	},
	minimalSaveState = true,
}

defineMaterial{
	name = "vortex",
	diffuseMap = "mod_assets/textures/vortex.tga",
	--specularMap = "mod_assets/textures/vortex_spec.tga",
	--normalMap = "mod_assets/textures/vortex_norm.tga",
	doubleSided = false,
	lighting = false,
	alphaTest = false,
	blendMode = "Translucent",
	textureAddressMode = "Wrap",
	glossiness = 60,
	depthBias = 0,
}

[minmay]

You should use world rotation (setWorldRotationAngles) instead of facing.

Even better, but are you sure it does not use the same thing under the hood? Though the Facing method also works with LoG1, unlike setWorldRotationAngles. Also, you have to change the increment from 0.02%4 to 1%360

It does not use the same thing under the hood, and this is easily testable. Setting facing to a non-integer value sets the GameObject's facing field to a non-integer value. Changing the object's world rotation (really just changing its transformation matrix) does not. I'm pretty sure non-integer facing will screw up around half the components in the game; in general I would strongly recommend you avoid using non-integer values for x, y, facing, elevation, and level. Almost everything useful you can accomplish with non-integer values in those can be accomplished much better by using world coordinates or subtileOffset instead.
Btw if you just want one model to rotate you can use Component:setRotationAngles() instead.

Code: Select all

function ersatzAnimator()
   x=x-1%360
   spinner:setWorldRotationAngles(0, x, 0)
end

This is a terrible way to do it, the rotation speed will then depend on the framerate (also that modulo operation will do nothing since 1%360 always evaluates to 1). Do this instead:

Code: Select all

function ersatzAnimator()
   x=(x-60*Time.deltaTime())%360
   spinner:setWorldRotationAngles(0, x, 0)
end

Then the speed will be framerate independent.

[Isaac]

You should use world rotation (setWorldRotationAngles) instead of facing.

Even better, but are you sure it does not use the same thing under the hood? Though the Facing method also works with LoG1, unlike setWorldRotationAngles. Also, you have to change the increment from 0.02%4 to 1%360

It does not use the same thing under the hood, and this is easily testable. Setting facing to a non-integer value sets the GameObject's facing field to a non-integer value. Changing the object's world rotation (really just changing its transformation matrix) does not.

I'm pretty sure non-integer facing will screw up around half the components in the game; in general I would strongly recommend you avoid using non-integer values for x, y, facing, elevation, and level. Almost everything useful you can accomplish with non-integer values in those can be accomplished much better by using world coordinates or subtileOffset instead.

I'd only use it for facing, which seems to work fine in both games ~for decorations. I certainly wouldn't use it for a monster, or interactive object. It'll crash if used on the party ~and the player tries to interact with anything.

Code: Select all

function ersatzAnimator()
   x=x-1%360
   spinner:setWorldRotationAngles(0, x, 0)
end

This is a terrible way to do it, the rotation speed will then depend on the framerate (also that modulo operation will do nothing since 1%360 always evaluates to 1). Do this instead:

Code: Select all

function ersatzAnimator()
   x=(x-60*Time.deltaTime())%360
   spinner:setWorldRotationAngles(0, x, 0)
end

Then the speed will be framerate independent.

Cool, I will use it then... But how would this affect the animation in a room that caused markedly different frame-rates depending on where you looked? (Meaning smoothed, or choppy increments?)

*How does it always evaluate to 1? When I test it, it always evaluates to 360 minus x, and the texture rotates just fine.

[minmay]

*How does it always evaluate to 1? When I test it, it always evaluates to 360 minus x, and the texture rotates just fine.

1%360 is 1. It seems to rotate because it is rotating. But it exceeds 360 and continues increasing. I assume your modulo operation was intended to make it wrap around at 360, but because of operator precedence (% is higher than binary -), it does literally nothing except waste time instead.

I'd only use it for facing, which seems to work fine in both games ~for decorations. I certainly wouldn't use it for a monster, or interactive object. It'll crash if used on the party ~and the player tries to interact with anything.

Yeah, it's a useful hack in Grimrock 1, in limited circumstances, but there's no reason to ever do it in Grimrock 2.

Cool, I will use it then... But how would this affect the animation in a room that caused markedly different frame-rates depending on where you looked? (Meaning smoothed, or choppy increments?)

You call that function I provided once every frame (a timer with a very short interval like 1ms will do this) and it changes the rotation proportionally to the frame delay. It will always rotate smoothly by 60 degrees per second regardless of variations in framerate. If you're doing (good) variable-framerate physics interaction, acceleration, or applying multiple angular velocities, then calculus has to come into play, but for variable-framerate translation or single-axis rotation at constant velocity, all you have to do is multiply the velocity by the frame delay.

[Isaac]

...

[THOM]

Juhu!!

If I wouldn't have you both...

[Skuggasveinn]

And BTW is ist possible to call/replace a material of a model, that consists of more than one material?
.

Just to comment on this, yes this can be done and seems to be overlooked by many mods, they are still doing it the LoG1 way of replacing the material with GMT and therefore have to ship a modified model file with the mod, If people just want to change a material for a model that ships with Grimrock this can be done with the materialOverrrides function that matches the existing material and overwrites it with your custom one, if you want to replace one of them you just list that one, if you want to replace them all you list them all.

Code: Select all

         class = "Model",
			model = "assets/models/env/forest_blocker_stone.fbx",
			materialOverrides = { ["forest_wall"] = "sx_winter_forest_wall", ["vegetation_atlas"] = "sx_winter_vegetation_atlas" },
			staticShadow = true,
			dissolveStart = 5,
			dissolveEnd = 7,

best regards.
Skuggaveinn

[Isaac]

materialOverrides = { ["forest_wall"] = "sx_winter_forest_wall", ["vegetation_atlas"] = "sx_winter_vegetation_atlas" },

That is really cool.