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

Showcase your libraries, tools and other projects that help your fellow love users.
JJSax
Prole
Posts: 47
Joined: Fri Apr 04, 2014 3:59 am

Re: Groverburger's Super Simple 3D Engine - v1.3

Post by JJSax »

siberian wrote: Tue Jan 28, 2020 4:40 am
JJSax wrote: Sun Jan 26, 2020 5:29 am I created a simple sphere in blender and am trying to use it in my scene. Half the triangle faces are missing however. Anyone know how to fix this?
Maybe you doesn't check "Triangulate Faces" in Export options?
That was it!!!!! I'm the noobest of noobs at blender. Maybe you know this as well. I'm running into an issue where if I get too far from an object, it will flicker as I move. What might be causing that?
User avatar
pgimeno
Party member
Posts: 3544
Joined: Sun Oct 18, 2015 2:58 pm

Re: Groverburger's Super Simple 3D Engine - v1.3

Post by pgimeno »

Could be Z fighting. When you have two faces very close to each other, with one occluding the other (i.e. covering it so it's not visible), the 3D system will try to find which one is closest to the camera, but on doing that, since the longer the distance the worse the precision of floats, it can happen that the face behind is sometimes visible at some spots, because the system can't accurately tell which one is farther. https://en.wikipedia.org/wiki/Z-fighting

Is that possibly the case? Do you have like two very close layers on your object?
JJSax
Prole
Posts: 47
Joined: Fri Apr 04, 2014 3:59 am

Re: Groverburger's Super Simple 3D Engine - v1.3

Post by JJSax »

pgimeno wrote: Wed Jan 29, 2020 3:27 pm Could be Z fighting. When you have two faces very close to each other, with one occluding the other (i.e. covering it so it's not visible), the 3D system will try to find which one is closest to the camera, but on doing that, since the longer the distance the worse the precision of floats, it can happen that the face behind is sometimes visible at some spots, because the system can't accurately tell which one is farther. https://en.wikipedia.org/wiki/Z-fighting

Is that possibly the case? Do you have like two very close layers on your object?
I do have some issues with texture stitching / z-fighting on another thing, but I'm not too concerned about it. I'm basically making a solar system simulator and the sun is just a hollow sphere so the volume between faces is greater than 0. The sun is still rather large when that happens. If it is z-fighting, then it's probably the edges of the triangles in the sphere. Also I'm having some similar issue with neptune flickering a little differently, even when I'm near it, I have one closer to the sun that is a clone of it that isn't having the issues. But it makes me think it has something to do with dealing with large numbers (something like 143 million) but that seems small to be hitting a limit.
chuchuw
Prole
Posts: 2
Joined: Thu Apr 30, 2020 11:57 am

Re: Groverburger's Super Simple 3D Engine - v1.3

Post by chuchuw »

Hello,

I am currently trying to point the camera towards a certain position with this library.
I spent some time trying to create a function like this, but I can't find the good formula :

Code: Select all

function lookAt (sc, cameraXYZ, targetXYZ) 
...
  sc.camera.angle.x = ...
  sc.camera.angle.y = ...
  sc.camera.angle.z = ...
 end
 
Does anyone have already coded something similar ?
Something like the scene.mouseLook, but for a specific point instead of a "movement".

Thank you for your attention :)
chuchuw
Prole
Posts: 2
Joined: Thu Apr 30, 2020 11:57 am

Re: Groverburger's 3D Engine (G3D) New and Improved!

Post by chuchuw »

Ok, I just found the current version has this : SetCameraAndLookAt(x,y,z, xAt,yAt,zAt)
Should do the work.
User avatar
groverburger
Prole
Posts: 49
Joined: Tue Oct 30, 2018 9:27 pm

Re: Groverburger's 3D Engine (G3D) New and Improved!

Post by groverburger »

chuchuw wrote: Mon Aug 17, 2020 3:48 pm Ok, I just found the current version has this : SetCameraAndLookAt(x,y,z, xAt,yAt,zAt)
Should do the work.
I saw your reply and had to add that feature! Hope it'll be helpful.
User avatar
Davidobot
Party member
Posts: 1226
Joined: Sat Mar 31, 2012 5:18 am
Location: Oxford, UK
Contact:

G3D love.js port

Post by Davidobot »

Hey goverburger!

I used your 3D demo as a basis for testing shaders in love.js. It's currently up as one of the online demos. You can check it out here: https://davidobot.net/3d/ (it's Chrome-only for now, due to web technologies)

EDIT: porting it over was nearly verbatim. The only changes were:

Code: Select all

-- main.lua
love.graphics.setCanvas({love.graphics.getCanvas(), depth=true})
love.graphics.clear(0, 0, 0, 0)
Skybox:draw()
Floor:draw()
Alakazam:draw()
love.graphics.setCanvas()

-- camera.lua
    CameraShader = love.graphics.newShader([[
		vec4 effect(vec4 color, Image tex, vec2 texture_coords, vec2 screen_coords)
		{
			vec4 texturecolor = Texel(tex, texture_coords);
			if (texturecolor.a == 0.0) { discard; }
			return texturecolor * color;
		}
	]], [[
        uniform mat4 projectionMatrix;
        uniform mat4 modelMatrix;
        uniform mat4 viewMatrix;

		vec4 position(mat4 transform_projection, vec4 vertex_position)
		{
			return projectionMatrix * viewMatrix * modelMatrix * vertex_position;
		}
    ]])
To get the depth-testing working properly and the shader compiling.
PM me on here or elsewhere if you'd like to discuss porting your game to Nintendo Switch via mazette!
personal page and a raycaster
User avatar
groverburger
Prole
Posts: 49
Joined: Tue Oct 30, 2018 9:27 pm

Re: G3D love.js port

Post by groverburger »

Davidobot wrote: Mon Sep 07, 2020 2:32 pm Hey goverburger!

I used your 3D demo as a basis for testing shaders in love.js. It's currently up as one of the online demos. You can check it out here: https://davidobot.net/3d/ (it's Chrome-only for now, due to web technologies)

EDIT: porting it over was nearly verbatim. The only changes were:

Code: Select all

-- main.lua
love.graphics.setCanvas({love.graphics.getCanvas(), depth=true})
love.graphics.clear(0, 0, 0, 0)
Skybox:draw()
Floor:draw()
Alakazam:draw()
love.graphics.setCanvas()

-- camera.lua
    CameraShader = love.graphics.newShader([[
		vec4 effect(vec4 color, Image tex, vec2 texture_coords, vec2 screen_coords)
		{
			vec4 texturecolor = Texel(tex, texture_coords);
			if (texturecolor.a == 0.0) { discard; }
			return texturecolor * color;
		}
	]], [[
        uniform mat4 projectionMatrix;
        uniform mat4 modelMatrix;
        uniform mat4 viewMatrix;

		vec4 position(mat4 transform_projection, vec4 vertex_position)
		{
			return projectionMatrix * viewMatrix * modelMatrix * vertex_position;
		}
    ]])
To get the depth-testing working properly and the shader compiling.
Amazing. Thanks for all the work you're doing for the community on maintaining love.js and it's also amazing that this engine basically just worked™.
User avatar
me_smash_videogame
Prole
Posts: 2
Joined: Mon Sep 21, 2020 4:05 am

Re: Groverburger's 3D Engine (G3D) New and Improved!

Post by me_smash_videogame »

First off I want to thank you so much for creating this. For the past 5-6 years I've been wanting to mess around with 3d gamemaking and between the complex game engines and confusing Java/C++ workspaces, I could never do it. This is the perfect level of "ground-up" for me. Now I have 2 problems that I did attempt to tinker with, but I just can't figure out what I'm looking at exactly with the obj importer and renderer. I hate to say it but I might need to be spoon-fed. My first problem is trying to get rid of UV data importing. When I make 3d models for my game, they are made with per-face coloring in mind so I never create a UV map as it's a waste of time and space. The problem with this is that if there's no UV data, the obj importer crashes the game. No matter what I removed or modified, I couldn't get the importer to stop worrying about missing UV data and I'm afraid some big chunks would have to be rewritten for this. My other problem is what I mentioned before, the per-face coloring. The material system I had in mind involves setting materials on the models to certain integers, and then lining the integers up with a list full of info on how to render it. Take for example a spear, all of the faces that make up the tip will be assigned the material "1" and all of the faces that make up the shaft will be assigned the material "14". 1 in the material list would tell the renderer to color the face grey as well as render specularity. 14 in the material list would tell the renderer to color the face brown and not render specularity. I imagine something like this could be accomplished similar to doing things like "love.graphics.setWireframe(true)" before a rendering task, but instead for individual faces.
User avatar
groverburger
Prole
Posts: 49
Joined: Tue Oct 30, 2018 9:27 pm

Re: Groverburger's 3D Engine (G3D) New and Improved!

Post by groverburger »

me_smash_videogame wrote: Mon Sep 21, 2020 4:51 am First off I want to thank you so much for creating this. For the past 5-6 years I've been wanting to mess around with 3d gamemaking and between the complex game engines and confusing Java/C++ workspaces, I could never do it. This is the perfect level of "ground-up" for me. Now I have 2 problems that I did attempt to tinker with, but I just can't figure out what I'm looking at exactly with the obj importer and renderer. I hate to say it but I might need to be spoon-fed. My first problem is trying to get rid of UV data importing. When I make 3d models for my game, they are made with per-face coloring in mind so I never create a UV map as it's a waste of time and space. The problem with this is that if there's no UV data, the obj importer crashes the game. No matter what I removed or modified, I couldn't get the importer to stop worrying about missing UV data and I'm afraid some big chunks would have to be rewritten for this. My other problem is what I mentioned before, the per-face coloring. The material system I had in mind involves setting materials on the models to certain integers, and then lining the integers up with a list full of info on how to render it. Take for example a spear, all of the faces that make up the tip will be assigned the material "1" and all of the faces that make up the shaft will be assigned the material "14". 1 in the material list would tell the renderer to color the face grey as well as render specularity. 14 in the material list would tell the renderer to color the face brown and not render specularity. I imagine something like this could be accomplished similar to doing things like "love.graphics.setWireframe(true)" before a rendering task, but instead for individual faces.
Thanks for the kind words! At least half of the reason I made this engine in the first place was to really understand how 3D rendering works for myself, so it's cool that I can help someone else in that regard.

Ignoring UV data in .obj loading is luckily a relatively simple procedure. We can just swap out lines 115-117 of objloader.lua like so:

Code: Select all

compiled[#compiled +1] = concatTables(verts[face[1]], {0,0}, normals[face[3]])
compiled[#compiled +1] = concatTables(verts[face[4]], {0,0}, normals[face[6]])
compiled[#compiled +1] = concatTables(verts[face[7]], {0,0}, normals[face[9]])
And any UVs will automatically be set to 0 when a .obj file is loaded.

This however does not solve your problem of materials for faces. In order to create materials as you're describing them, you would need to split up your models to have exactly one material per model.

This is because of the fact that you can only (at least to my knowledge) have one shader effect a mesh at a time, and in order to do things like change specularity or diffusion per face you would have to apply a different shader to a different model containing that face.

Tangentially related to your material property idea, creating some property like coloring a face is extremely similar to the concept of UVs, and can be done with UVs by setting all UV coordinates on a face to point to the same pixel effectively making that face the color of that pixel.

There seems to be no way around needing some vertex property in your mesh determining the color of the vertex. Because of this, I would advise you to stick to UVs as programs like Blender already have support and really convenient tools for UV editing.

Hope that helps.
Post Reply

Who is online

Users browsing this forum: No registered users and 51 guests