LÖVE

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

RNavega wrote: ↑Sun Sep 27, 2020 11:56 am @groveburger what exactly is the history involving G3D and SS3D?
- G3D's code has more recent commits, while SS3D is older but has more features (it also supports that UV-less OBJ loader that people are talking about).
- I can't find a proper repo for SS3D but for forks to your G3D. For example: https://github.com/AndrewMicallef/ss3d

me_smash_videogame wrote: ↑Wed Sep 23, 2020 10:02 pm That code doesn't actually skip UV data, it just prevents detected UV data from being put into a list. I may not have mentioned that my models not only don't have UV data on export, but they're completely missing the lines as well which is what's crashing the obj loader. As for the face coloring issue, that's going to be my deal breaker with this. If you ever end up finding a way to do that then let me know.

groverburger wrote: ↑Mon Sep 28, 2020 8:50 pm Thanks for the question. g3d is a rewrite and renaming of SS3D.

SS3D's code was very messy, bloated, inefficient, and all-around cumbersome to use. The code eventually got bad enough that I didn't even understand half of it myself. I decided a few months ago that I should just rewrite the whole thing to be clean and easily understood, so I did.

RNavega wrote: ↑Mon Sep 28, 2020 9:58 pm Ah, that makes sense. Thanks a lot for the info (and the engine too, it's a gem).

One thing I'm curious to test is if there's a performance increase by using love.math.Transform objects instead of Lua tables, since they can be used as 4x4 matrices.
People also recommend using FFI objects like C structs or C float arrays, but from what I tested, indexed reads and writes using FFI objects are not faster than plain Lua array tables. Maybe this is meant for when using vanilla luac, and not LuaJIT which optimizes things further.

RNavega wrote: ↑Mon Sep 28, 2020 9:58 pm One thing I'm curious to test is if there's a performance increase by using love.math.Transform objects instead of Lua tables, since they can be used as 4x4 matrices.