Groverburger's 3D Engine (g3d) v1.5.2 Release

[grump]

Code: Select all

	#define LIGHTS 16 uniform PointLight pointLights[LIGHTS];

The problem is this line. I leave it up to you to find the mistake.

Also, don't pass the PointLight structure to functions, it will fail on older drivers. Pass the light index instead and access the array in the function.

[4aiman]

@4vZEROv
Yeah, I can read
Not sure why people think comments like that will help. Especially since I'm dumb.
The question implied I'd like to know why the thing isn't defined when it clearly (to me anyway) is.
Whether that was a joke or a genuine attempt to help - it flew way over my head. I am truly sorry.


@grump
My cognitive skills are greatly exaggerated
That line was copied from the groverburger's old game. And it works there just fine.
I can only guess that is is supposed to create an array of point lights.

In the original it is separated into two lines, but I have no idea why.
I've split those - just like in the original - and it doesn't crash anymore.
HUGE THANKS!


@pgimeno
Thanks for the wiki page and the head-ups.
My GPU isn't that old, but in Love 11.3 is utilizes OGL 3.3 instead 4.5/4.6, so the issue might still be present.

[pgimeno]

The question implied I'd like to know why the thing isn't defined when it clearly (to me anyway) is.

The error doesn't say that it isn't defined. It says that it doesn't exist. The help text says that a common error is to define (hence it is defined) but then not use the variable.

While it doesn't seem to be the case of your driver (because it worked, at the end), for some drivers it happens that when a variable is defined but then not used, the GLSL compiler optimizes out that variable, and when trying to send values to it, the variable no longer exists. It's a fairly common gotcha: a program works just fine in your system, but when sending it to someone who has a driver that optimizes the variable out, it suddenly crashes with that error.

For example, this main.lua crashes with my graphics driver, but not with some others:

Code: Select all

love.graphics.newShader[[
  uniform float x; // defined, but not used anywhere
  vec4 effect(vec4 col, Image tex, vec2 texpos, vec2 scrpos) { return col * Texel(tex, texpos); }
]]:send('x', 1) -- 'x' is optimized out and this causes an error because it doesn't exist

In the original it is separated into two lines, but I have no idea why.

I don't know much GLSL, but by analogy with C, lines starting with # are preprocessor directives, and they consist of a single line (except when the last character in the line is a \ symbol, which means that it continues on the next line). In the case of #define, it defines a macro with the name that appears immediately after #define, to be everything between the next non-blank character after the name, and the end of the line. In this case, the idea was to define the macro 'LIGHTS' to be '16', but the way you wrote it, it was defining the macro 'LIGHTS' to be '16 uniform PointLight pointLights[LIGHTS];'. These macros are text replacement macros; if 'LIGHTS' was used anywhere else, it would be replaced by '16 uniform PointLight pointLights[LIGHTS];', most likely causing a syntax error.

Apologies to Groverburger for diverting his thread even more.

[Williac]

First I really am enjoying using LÖVE and G3d. Lua is enjoyable to work with and I am thrilled LÖVE works on Android and Linux. I have looked at G3d's comments and googled a few things and had some some success getting done. I can get a model's origin's onscreen x,y to use for selecting a specific model but I would like to be able to pick irregular shaped models. I am hoping to use the

Code: Select all

collisions:rayIntersection(src_1, src_2, src_3, dir_1, dir_2, dir_3)

function. I use the g3d.camera.position for src_1,2,3. I have tried fpsController.direction and fpsController.pitch for the dir arguments placing them in different places with no luck. I have also tried getting the dir arguments by getting values from the viewmatrix. I have managed to get the ray to check from the top or bottom. The last attempt MoonBeam=Moon:rayIntersection(camX, camY, camZ, viewM[3],viewM[7],viewM[11]) seems to gets the opposite of where the camera is looking. I think I am missing something simple. I anyone could tell me what Im missing Id really appreciate it.

[4vZEROv]

I don't understand, you wan't a ray facing the camera ?

If that's the case camera.target as dir_1, dir_2, dir_3

[Williac]

camera.target!!! I cant believe I didnt see/think of that!!! Sorry for asking such a silly question and Thank you so much for responding so fast!!!

[groverburger]

Hey everyone, just released a new update - v1.3!

Changes:
- Added collision functions
- Added basic quaternion rotation support
- Matrices are now a class so they do not have be re-allocated every frame
- Vectors no longer use tables so they do not have to be allocated to the heap
- Fixed bugs where g3d's camera wouldn't initialize its matrices correctly on startup

Here's a first-person demo showing off the new collision functions:
You can find the code for this demo in this seperate Github repo here: https://github.com/groverburger/g3d_fps

[pgimeno]

- Added basic quaternion rotation support

Code: Select all

function model:setQuaternionRotation(x,y,z,angle)

May I suggest to call it model:setAxisAngleRotation? I'd expect a true setQuaternionRotation to accept a quaternion, i.e. x,y,z,w (or w,x,y,z, depending on taste) instead of x,y,z,angle.

As for the implementation in matrix:setTransformationMatrix, caching math.sin(angle/2) in a local would be a good idea. Maybe even doing angle=angle/2 in advance instead of repeating it, similar to how you normalize x,y,z in advance.

Here's a first-person demo showing off the new collision functions:

I can climb one of the red ramps (the one visible in the screenshot). Is that expected?

[groverburger]

Code: Select all

function model:setQuaternionRotation(x,y,z,angle)

May I suggest to call it model:setAxisAngleRotation? I'd expect a true setQuaternionRotation to accept a quaternion, i.e. x,y,z,w (or w,x,y,z, depending on taste) instead of x,y,z,angle.

This is a quaternion rotation either way, I just called the "w" component "angle" inside of the function. I can understand why changing this to w would be better for some, as it would look more like standard quaternion notation that way.

As for the implementation in matrix:setTransformationMatrix, caching math.sin(angle/2) in a local would be a good idea. Maybe even doing angle=angle/2 in advance instead of repeating it, similar to how you normalize x,y,z in advance.

Yeah good point. I'll probably make this change in some future update. It is only four division operations, I don't expect it to make any noticeable performance change in any scenerio : P
Did you mean in the model:setQuaternionRotation function? I don't see any reference to angle/2 in matrix:setTransformationMatrix.

I can climb one of the red ramps (the one visible in the screenshot). Is that expected?

Yeah you can just barely climb one of the smaller red ramps, it is a very slow and tedious climb. It's steep enough to not be considered floor though, so you can't jump when standing on it.

I'm most likely going to make all the ramps slide the player faster, so this shouldn't stay a problem.

[pgimeno]

May I suggest to call it model:setAxisAngleRotation? I'd expect a true setQuaternionRotation to accept a quaternion, i.e. x,y,z,w (or w,x,y,z, depending on taste) instead of x,y,z,angle.

This is a quaternion rotation either way, I just called the "w" component "angle" inside of the function. I can understand why changing this to w would be better for some, as it would look more like standard quaternion notation that way.

No, the w of a quaternion is not the angle! It's the real component, which for a quaternion representing a pure rotation (i.e. normalized), equals the cosine of half the rotation angle. The name of the function suggests that it accepts a quaternion, but an axis/angle rotation is not a quaternion, even if the conversion to quaternion is fairly simple. That's why I suggest choosing a name that doesn't cause this confusion. A quaternion is what you use internally as rotation[1..4]. I'd expect a function called setQuaternionRotation to set rotation[1..4] to each input parameter. Something like:

Code: Select all

function model:setQuaternionRotation(x,y,z,w)
    self.rotation[1] = x
    self.rotation[2] = y
    self.rotation[3] = z
    self.rotation[4] = w
end

while the function that you call setQuaternionRotation sets the axis and angle of rotation, hence why I suggest calling it setAxisAngleRotation instead.

Did you mean in the model:setQuaternionRotation function? I don't see any reference to angle/2 in matrix:setTransformationMatrix.

Indeed, sorry. I was watching both, because setTransformationMatrix contains many duplicate factors, and I mentioned the wrong one. But the ones in setTransformationMatrix imply many locals and precalculations, so I hesitated whether to mention it, and I finally didn't.

Yeah you can just barely climb one of the smaller red ramps, it is a very slow and tedious climb. It's steep enough to not be considered floor though, so you can't jump when standing on it.

OK, just making sure it was intentional