LÖVE

groverburger wrote: ↑Sat Jan 16, 2021 10:55 pm

yetneverdone wrote: ↑Sat Jan 16, 2021 7:01 am 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!)

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

yetneverdone wrote: ↑Sun Jan 17, 2021 12:59 am 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.

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

RNavega wrote: ↑Sun Jan 17, 2021 4:05 am 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.

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

local matrices = require "g3d/matrices"

4aiman wrote: ↑Wed Jan 20, 2021 5:51 pm

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

4aiman wrote: ↑Wed Jan 20, 2021 5:51 pm 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.

g3d.camera.firstPersonLook(dx,-dy)

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

groverburger wrote: ↑Wed Jan 20, 2021 10:47 pm 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.

grump wrote: ↑Wed Jan 20, 2021 11:49 pm 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.

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