Page 4 of 22

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

Posted: Tue Jan 28, 2020 6:47 pm
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?

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

Posted: Wed Jan 29, 2020 3:27 pm
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?

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

Posted: Thu Jan 30, 2020 2:04 am
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.

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

Posted: Thu Aug 13, 2020 3:20 pm
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 :)

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

Posted: Mon Aug 17, 2020 3:48 pm
by chuchuw
Ok, I just found the current version has this : SetCameraAndLookAt(x,y,z, xAt,yAt,zAt)
Should do the work.

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

Posted: Wed Aug 19, 2020 3:44 am
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.

G3D love.js port

Posted: Mon Sep 07, 2020 2:32 pm
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.

Re: G3D love.js port

Posted: Fri Sep 11, 2020 6:43 am
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™.

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

Posted: Mon Sep 21, 2020 4:51 am
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.

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

Posted: Wed Sep 23, 2020 6:13 am
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.