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

[yetneverdone]

Yeah im keeping an eye on the lib, but why is the lib global? I think people would want the lib/framework to be localized and decoupled globally.

Yeah I understand that complaint - I'm considering doing kinda what p5js does and having a global/non-global version of the lib.

The main reason the lib is global is because I pulled the files that are now called g3d out of a project I was working on and I didn't change them to be non-global.
I'm worried changing this that would break compatibility, and I've already broken compatibility once.

I also think having the lib in the global namespace may make the source code easier for people to read and understand themselves, which is something I aim for with g3d.

So, I'm open to more feedback here.

(Also if anyone is wondering I mistyped and titled this update v1.2 when I should have typed v1.1 -- oops!)

I vote for separating the library into submodules as well like:

Code: Select all

local Model = require("g3d.model")
local Camera = require("g3d.camera")
local Loader = require("g3d.objLoader")
-- and so on

This would be cleaner imo.

Anyway im looking forward to using this library to learn basic 3d gamedev soon!

PS. I would be willing to help with refactoring the code to make more modular in case you decide to make it as suggested above.

[groverburger]

I vote for separating the library into submodules as well like:

Code: Select all

local Model = require("g3d.model")
local Camera = require("g3d.camera")
local Loader = require("g3d.objLoader")
-- and so on

This would be cleaner imo.

Anyway im looking forward to using this library to learn basic 3d gamedev soon!

PS. I would be willing to help with refactoring the code to make more modular in case you decide to make it as suggested above.

Ok, I was curious about how g3d would look if it was rewritten as a module, so I gave it a shot in a separate branch.

You can check it out here: https://github.com/groverburger/g3d/tree/module

The g3d library instead of entering _G is instead returned as a table containing only two modules: camera and model. So you can do things like:

Code: Select all

g3d = require "g3d"
myModel = g3d.model.new("objpath", "texturepath")

So now all of the internal math stuff is not accessible to the end user by default, which I think is a good thing - you can of course still require it if you want.

If anyone has any thoughts about this, I'm all ears.

[RNavega]

I haven't tested it, but if you're supposed to require the helper modules during your program, like the 'matrices' module for example, wouldn't G3D_PATH still need to exist then?

EDIT: Hm, this could be solved by putting all the helper modules into the 'g3d' object, then you can safely clear G3D_PATH because the modules are accessible from the 'g3d' object.

[groverburger]

I haven't tested it, but if you're supposed to require the helper modules during your program, like the 'matrices' module for example, wouldn't G3D_PATH still need to exist then?

EDIT: Hm, this could be solved by putting all the helper modules into the 'g3d' object, then you can safely clear G3D_PATH because the modules are accessible from the 'g3d' object.

The user is not expected to load submodules themselves.

The user is instead expected to load g3d, which itself automatically contains the two main submodules: camera and model like so:

Code: Select all

g3d = require "g3d"
-- or
local g3d = require "g3d"

The camera and model submodules use the other submodules (like matrices, vectors, shader, and objloader) internally, so I don't think it makes sense to expose those to the end user through requiring g3d.

The end user could still "manually" load the hidden submodules if they want, using some syntax like:

Code: Select all

local matrices = require "g3d/matrices"

In which case I don't think it makes sense to expose the G3D_PATH variable. The G3D_PATH variable is only used for loading submodules automatically in g3d.

[4aiman]

Hey there, @groverburger o/

Could you help me with something?

I've been tinkering with your engine using love 11.3 and have found a weird issue.
The details and the way to recreate the issue are on the Github, but basically there's something with Z-order and normals (only a guess).

Normals of the cuboids are pointing *inside* them, so they should've been invisible from the outside.

The issue is persistent thoughout g3d-master, g3d-release-1.1 and g3d-module and can be seen even on the supplied with the engine demo (albeit not so evidently).
I'm on windows 10 (2020H) with GTX1660 and Ryzen3600.

[4vZEROv]

You need to create a canvas and draw inside it :

Code: Select all

function love.load()
        cube   = g3d.Model('assets/obj/cube.obj'  , _ , {1, 0, 0}, _, {.5, .5, .5})
	canvas = love.graphics.newCanvas()
end

function love.draw()
	love.graphics.setCanvas({canvas, depth=true})
	love.graphics.clear()
		cube:draw()
	love.graphics.setCanvas()

	love.graphics.draw(canvas, 0, 0)
end

[groverburger]

Hey there, @groverburger o/

Could you help me with something?

I've been tinkering with your engine using love 11.3 and have found a weird issue.
The details and the way to recreate the issue are on the Github, but basically there's something with Z-order and normals (only a guess).

Normals of the cuboids are pointing *inside* them, so they should've been invisible from the outside.

The issue is persistent thoughout g3d-master, g3d-release-1.1 and g3d-module and can be seen even on the supplied with the engine demo (albeit not so evidently).
I'm on windows 10 (2020H) with GTX1660 and Ryzen3600.

Hey!
I responded to your Github issue - this problem looks like it may be a graphics card thing. Changing the depth mode might help, I saw that it did for when g3d was ported to web. Changing love.graphics.setDepthMode("lequal", true) to love.graphics.setDepthMode("gequal", true) might fix the issue here for you.

Does 4vZEROv's suggestion fix the problem? I can't test this because I haven't been able to reproduce this bug on my computers.
If not, then fixing this issue outright might be a bit more tricky and may require pulling some weird depth testing and rendering tricks on g3d's initialization, again I'm not quite sure.

The business about normals for the different models should not matter, as backface culling is not enabled by default.

I also merged the "module" branch into the main branch, so now everything is out of the global scope. Just updated the documentation too!

[4aiman]

Yup, using the canvas it shows up just fine. YAY!!!
Had to invert the dy, tho

Code: Select all

g3d.camera.firstPersonLook(dx,-dy)

Also, reposting from github:

Code: Select all

love.graphics.setDepthMode("gequal", true)

did nothing, the picture is the same in any of the two modes.
Tried both mine and demo projects.

I think I've found the source of the issue.

Code: Select all

print( love.graphics.getRendererInfo( ))

yields

Code: Select all

OpenGL  3.3.0 NVIDIA 460.89     NVIDIA Corporation      GeForce GTX 1660 SUPER/PCIe/SSE2

which is weird, since the GPU is capable of OGL 4.6.

Love2d v 0.10.2 returns this

Code: Select all

OpenGL  4.6.0 NVIDIA 460.89     NVIDIA Corporation      GeForce GTX 1660 SUPER/PCIe/SSE2

which is perfectly fine.

And when I try Angle with 11.3, I'm getting this

Code: Select all

OpenGL ES       OpenGL ES 3.0.0 (ANGLE 2.1.14699 git hash: 60015ff672d9)        Google Inc.     ANGLE (NVIDIA GeForce GTX 1660 SUPER Direct3D11 vs_5_0 ps_5_0)

and the issue persists.

I've tried x86 and x64 versions of love2d, to no avail.
Since love2d v 0.10.2 gets it right, it's probably something introduced in love 11. And it goes back to 11.0.

This is either love2d thing or something was changed in newer GPU's drivers which is preventing utilizing OGL4.6

Thanks, folks! Really appreciate the help!

[grump]

I can't test this because I haven't been able to reproduce this bug on my computers.
If not, then fixing this issue outright might be a bit more tricky and may require pulling some weird depth testing and rendering tricks on g3d's initialization, again I'm not quite sure.

The issue is that you don't set up a depth buffer in your code. You are calling setDepthMode, but that does nothing if there is no depth buffer. So any code that does not draw strictly back to front will have depth sorting issues.

[groverburger]

4aiman, glad you got it working! Thanks for your detailed post, too!

The issue is that you don't set up a depth buffer in your code. You are calling setDepthMode, but that does nothing if there is no depth buffer. So any code that does not draw strictly back to front will have depth sorting issues.

grump, there does appear to be some default depth buffer. When removing the setDepthMode call the only thing that is respected is the draw order and there is no z-buffer, however that call is made in init.lua so that the love.draw() function of the demo can look like this:

Code: Select all

function love.draw()
    Earth:draw()
    Moon:draw()
    Background:draw()
end

Which renders the background last and still draws everything to the screen correctly. Therefore, there has to be some default depth buffer.

However, 4aiman's post demonstrates that this approach seemingly doesn't always work. It may be safer to just always render to a depth-enabled canvas like 4vZEROv mentioned, and then render that canvas to the screen.