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

[Rigachupe]

Just to remember correctly, what are the axis oriented in g3d vs opengl?

i see that:
left= -x
right=+x
up=-y
down=+y
infront=+z
backwards=-z

Should the Y or Z axis by oriented otherwise?

[pgimeno]

OpenGL does not have an orientation, but it has a left-handed coordinate system. If you consider the OpenGL view a top view, g3d and OpenGL have the same axis choices (except for the sign of Z).

You could consider +X = east, +Y = north, +Z = down in OpenGL and up in g3d.

[Rigachupe]

I was using the right handed from opengl. Here are some example how various program use axes. Just to see how confusing it can be to then either rotate model or use something like scale(-1,-1,1) to turn around model.

magicka voxel.png (5.75 KiB) Viewed 12712 times

blender-ue5.png (134.01 KiB) Viewed 12712 times

blockbench.png (16.96 KiB) Viewed 12712 times

[zorg]

It sadly can get confusing.

[pgimeno]

To be more specific, the default OpenGL coordinate system is a 2x2x2 cube centred on 0,0,0 with x=-1 being the left side of the screen drawing area, x=1 right, y=-1 bottom, y=1 top, and z growing away from the user, towards the back of the monitor (keywords: normalized device coordinates). Fortunately, you're just one projection matrix away from whatever axis convention and handedness you want. and you need a projection matrix anyway if you plan to use 3D.

[ArchAngel075]

Hi there, Long time lurker

Been tinkering a project and have implemented some "OK" network code that syncs objects between clients and server...

I use a simulation approach, so instead of sending position and rotation thousands of times a second, Instead i send keystates and position/rotation at time of event. The client(s) then proceed to simulate the outcome from this information.

This works for simple 2D movement tests (literally circles i move around on screen)

Though for implementing 3D I struggle to wrap around how i would use the simulation approach.

My first thought was to replicate the first person camera as one of my objects (using rxi/classic) - then to send initial states with keypresses. Handing over to the "ThreeDee" object which given the direction, pitch, look target and xyz position simulates.

Im just wondering if this is the best way to go about this. as i have no intention of slamming the network with thousands of position and rotation updates a second.

Is there a better way of receiving XYZ position, pitch and direction and simulating given input (WASD SPACE SHIFT) using this library?

Otherwise fantastic work!
PS I may have pushed a Raspberry Pi2b to far trying to run Lead Haul on it for fun and giggles.

I tried running a basic 5x5 Cube world game on the Pi and got horrid lag. Either it isnt cut out for it or i write horribly inefficient code

PS 3, given (PS 2) - I ask if there is optimisations around loading models. IE can i load a model once and reuse it with altered textures and scale etc. OR reworded. IF i load a model 25 times. Is it loaded into memory 25 times?

[ArchAngel075]

Sorry for the double post

I have made a PR to bring forward multiple camera support while trying to not introduce too big a breaking change.
https://github.com/groverburger/g3d/pull/41

I feel the inclusion of multiple camera support can be beneficial for games that want cctv like interactions or portals, mini view ports etc.

[Sulunia]

Hello lads!

First off, congratulations on the library, I have learned a crazy lot in these last few days just playing around it and the power of 3D

So, after developing a few bits and bobs, I've decided to tackle ambient + diffuse lighting for objects in the gameworld. After studying quite a bit, I managed to get most of it working, except for one bit which is driving me nuts.

If I apply a rotation to an object, the light source rotates with the model, and the final lighting calculation comes out wrong:

Screenshot 2023-05-24 154326.png (117.75 KiB) Viewed 11092 times

And I'm stumped after reading and re-reading the theory and analyzing the vertex/fragment shaders as to why this happens . Could someone clarify? I feel like I'm missing something obvious here.

I also attached a love file that reproduces the issue (with a hopefully not too complex code, most of it is in gameScene.lua, GroundDrawSystem.lua and vertex/frag shaders)

@edit
I have also realized there is an implementation of this a few pages ago in this very thread. I'll look into it to see what I'm doing wrong and fix it...

@edit2

I figured it out! Lots of wrong things:
- I was not multiplying the model normal with the matrix model to figure out applied rotations
- worldPosition var was not `varying`, being set to a uniform instead (and value never changed)

I managed to fix it now, and lighting works as expected! Great stuff.

aaaScreenshot 2023-05-24 154326.png (103.73 KiB) Viewed 11029 times

[yal2du]

If you want to use a depth buffer with the main screen, you need to set it up in love.conf (or love.window.setMode) - just setting t.window.depth = 24 should do it, but I haven't seen that being done in the g3d code I've looked at.

this (adding t.window.depth to conf.lua) fixes the depth testing issues on grovenburger's simplest_3d and g3d_voxel demo repo's on github. (at least for win10/radeon)