Rotate image on a quad

[darkfrei]

Thats nearly perfect! Only issue is it needs to be able to be rotated around a specific point, rather than just 0,0 so it doesn't shift when a physics object rotate. I tried to figure out how to do it, though I got wrong (though interesting to look at) results.

Maybe just shift the vertices at 0.5 of width/hight as

Code: Select all

	local vertices = {
		{-s/2, -s/2,  0, 0, 1,1,1},
		{ s/2, -s/2,  n, 0, 1,1,1},
		{-s/2,  s/2,  0, n, 1,1,1},
		{ s/2,  s/2,  n, n, 1,1,1},
	}

and move it by the drawing as

Code: Select all

love.graphics.draw(mesh, s/2, s/2)

(don't forget to change from fan to strip)

Code: Select all

	mesh = love.graphics.newMesh( vertices, "strip")

[Bigfoot71]

I managed to modify the function of darkfei in order to apply the rotation around a given point:

Code: Select all

local function rotateTexMesh (mesh, s, n, angle, ox, oy)

	ox, oy = ox or 0, oy or 0

	local _cos = math.cos(angle)
	local _sin = math.sin(angle)

	local x1, y1 = 0, 0
	local x2, y2 = s, 0
	local x3, y3 = 0, s
	local x4, y4 = s, s

	local u1 =  (x1 - ox)*_cos + (y1 - oy)*_sin + ox
	local v1 =  (x1 - ox)*_sin - (y1 - oy)*_cos + oy
	local u2 =  (x2 - ox)*_cos + (y2 - oy)*_sin + ox
	local v2 =  (x2 - ox)*_sin - (y2 - oy)*_cos + oy
	local u3 =  (x3 - ox)*_cos + (y3 - oy)*_sin + ox
	local v3 =  (x3 - ox)*_sin - (y3 - oy)*_cos + oy
	local u4 =  (x4 - ox)*_cos + (y4 - oy)*_sin + ox
	local v4 =  (x4 - ox)*_sin - (y4 - oy)*_cos + oy

	local tex_size = s/n

	mesh:setVertex(1, x1, y1, u1/tex_size, v1/tex_size)
	mesh:setVertex(2, x2, y2, u2/tex_size, v2/tex_size)
	mesh:setVertex(3, x3, y3, u3/tex_size, v3/tex_size)
	mesh:setVertex(4, x4, y4, u4/tex_size, v4/tex_size)

end

We can certainly optimize it mathematically but we can now define the origin of rotation, here are examples:

(0,0);


(ox,oy):


Edit: Looking back on it by readapting my first solution, we could have achieved the same thing, to see what is the most efficient, personally I will bet on the meshes although it gives the impression that there are more calculations to do in this case, if someone is brave enough

[RNavega]

I still don't get what you guys are trying to do n_n

Each platform has a repeating texture, which I have managed using setWrap(), then drawing it on a quad the size of the screen, and then finally stenciling it - however my issue is that now they are physics objects, they can also rotate. Just setting r on the draw function rotates the whole quad and not just the texture, which means it no longer covers the whole screen.

Is it like this?
- The user can manipulate a polygon by dragging its corners / adding new corners.
- While dragging, the texture inside the polygon must repeat.
- Once you "freeze" the polygon as finished, the texture should stay "locked" to it, rotating & scaling with it.

Mockup in Blender:

GIF 30-01-2023.gif (574.58 KiB) Viewed 2311 times

[Bobble68]

Is it like this?
- The user can manipulate a polygon by dragging its corners / adding new corners.
- While dragging, the texture inside the polygon must repeat.
- Once you "freeze" the polygon as finished, the texture should stay "locked" to it, rotating & scaling with it.

Ah the main issue isn't about being able to modify the polygon, it's just filling it with a texture that will behave sensibly when physics are added - in this case, rotating it around it's centre of mass. I wasn't expecting all of this to require so much maths, honestly I was just expecting it to be a function or argument I didn't know about

Bigfoot71's code seems to be what I was looking for though, thank you so much!

[RNavega]

I wasn't expecting all of this to require so much maths, honestly I was just expecting it to be a function or argument I didn't know about

Hang on, I'm under the impression that you're having an XY problem: you want to find out how to rotate that repeating texture for your fullscreen quad, but what you actually want to do is draw a textured polygon that can move around.

You can do that by setting texture coordinates on the vertices of the polygon when you create it as a Mesh object with love.graphics.newMesh (has samples if you scroll down the page).

That is what texture mapping is. You can read about the theory in here:
- https://learnopengl.com/Getting-started/Textures
- https://viterbi-web.usc.edu/~jbarbic/cs ... xtures.pdf

Then it works just like the GIF I posted, it's happening in Blender but the visual result will be the same in Löve's OpenGL renderer.

[Bigfoot71]

Ah the main issue isn't about being able to modify the polygon, it's just filling it with a texture that will behave sensibly when physics are added - in this case, rotating it around it's centre of mass. I wasn't expecting all of this to require so much maths, honestly I was just expecting it to be a function or argument I didn't know about

Bigfoot71's code seems to be what I was looking for though, thank you so much!

This is often the case when you want to do very specific things but by re-adapting my first example (even if I didn't quite understand what you wanted) you can also achieve this with a lot less math but it will be much less optimized as I wanted to say before.

I did it quickly if you want to see.


Anyway, meshes is in this case the most efficient possible although not the simplest (I made this other example just for fun and you may still be able to learn a few things), in any case if you need help to mathematically readapt the function that I shared with you, don't hesitate

[Sasha264]

What I was looking for before was to just fill the whole screen, what I'm trying to avoid is drawing outside the screen area, and not leaving any undrawn area, otherwise you get these corners.

Quick note: from the performance point of view you don't have to worry about drawing outside the screen area, because it is absolutely ok. "Invisible pixels" are efficiently discarded by the GPU rasterizer. I once had quads that were literally a million times bigger than my screen and it worked just fine.

On the other hand, if you have a lot (like thousands) of objects (quads, triangles, meshes or whatever) that are completely outside of visible area — that is a different story. You can think about how to discard them somehow by hands.

This is rooted in the difference between vertex and fragment shaders. Vertex shaders are called for every vertex disregarded by their "visibility", but fragment shaders are only called for every visible pixel. Strictly speaking the is no such thing as invisible pixel, there is simply no pixel And of course, generally visible = from the render target point of view, not from screen point of view, but here looks like render target is just the screen.

[darkfrei]

I like how it rotates:

Animation (60).gif (3.05 MiB) Viewed 2213 times