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?
Groverburger's 3D Engine (g3d) v1.5.2 Release
Re: Groverburger's Super Simple 3D Engine - v1.3
Re: Groverburger's Super Simple 3D Engine - v1.3
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?
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
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.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?
Re: Groverburger's Super Simple 3D Engine - v1.3
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 :
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
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
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!
Ok, I just found the current version has this : SetCameraAndLookAt(x,y,z, xAt,yAt,zAt)
Should do the work.
Should do the work.
- groverburger
- Prole
- Posts: 49
- Joined: Tue Oct 30, 2018 9:27 pm
G3D love.js port
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:
To get the depth-testing working properly and the shader compiling.
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;
}
]])
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
personal page and a raycaster
- groverburger
- Prole
- Posts: 49
- Joined: Tue Oct 30, 2018 9:27 pm
Re: G3D love.js port
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™.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:To get the depth-testing working properly and the shader compiling.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; } ]])
- me_smash_videogame
- Prole
- Posts: 2
- Joined: Mon Sep 21, 2020 4:05 am
Re: Groverburger's 3D Engine (G3D) New and Improved!
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.
- groverburger
- Prole
- Posts: 49
- Joined: Tue Oct 30, 2018 9:27 pm
Re: Groverburger's 3D Engine (G3D) New and Improved!
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.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.
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]])
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.
Who is online
Users browsing this forum: No registered users and 8 guests