oops I think I actually came down harder on the API doc than I meant to... sorry about that. >.>
yeah I'll do so, though I'd be more inclined to if it weren't Microsoft GitHub... not like there isn't a decent alternative mentioned on my GitHub Profile ;)
(my projects are currently pulled off the alternative due to a scummy analytics move that was rolled back from community backlash, they'll be back up eventually)
and btw, a GPU is much faster than a CPU (limited recursion), and has hundreds of extra GLSL compute units to back
1k polygons should be nothing for even my 82810E (not to say you're free to go all out though as there is a limit)
but even then, if you use a display list over calling glVertex3f() from the CPU, your code will be even faster.
but what's better than static display lists is dynamic vertex arrays with modern-OpenGL
if you know what Miku Miku Dance is, you'll know just how much a GPU can really take
the amount of polygons in PMD/PMX models will make you want to stab yourself
just look at the default model in the CustomSteve mod for Minecraft, and you'll probably be more forgiving of my model
my GT 430 has little issue rendering that model (there's a bit of delay, but I still get 40+ FPS in Minecraft)
if you need a number, that's at least 11k polygons... I forget exactly though as it's been a few years and I lost the blender model...
I promise you, if you get any frame lag in Minetest, it's most likely within the CPU-sided frame loop. ;)
also, B3D isn't too great as it's vertex-based with no vector arrays (only slightly better than the RAW triangle format)
it's actually better for smaller models on disk as it writes duplicate f32 vectors for more complex models.
(I actually did a filesize comparison with Brawl Pikachu (4k polygons), and B3D came out to ~4MiB vs the original MDL0 at ~100KiB)
as for VRAM, the format should be parsed and optimized into GL vector arrays (hopefully removing the duplicate vectors the toxic format creates)
too bad Minetest-Irrlicht removes IQM as that's a better model format than B3D that 100% matches GL vertex arrays
(it's pretty much a direct VRAM export)
buuuuut it lacks material (brush) support in comparison.
alright, I have improved the visual quality of the mesh and am hoping there will be less pixel clipping (can't tell in Blender)
not sure if I have anti-aliasing on, but I probably do... it doesn't work in Minetest, so if that's the cause, you're kinda stuck with it for now until we have better rendering...
... or until GL lines and points are actually supported appropriately as those don't clip
but anyways, I've also optimized the meshes, so there's about 894 quads or 1788 triangles total for all 3 meshes:
chunks: 40 quads, 80 triangles
vchunks: 478 quads, 956 triangles (the dots at the bottom and top are done with quads, and I hate every bit of it... GL points would be soooooo much better)
nodes: 376 quads, 752 triangles
I could get rid of the dots for lines, but I'm going for a particular style
a textured quad with alpha would be better here, but that'd mean I'd have to change my themes about and split them into multiple textures, as well as destroy my current system.
if the engine could be made to support unofficial obj face lines and points, you could maintain the UVs I use for theming
(GL lines and points do support UV mapping, but the official obj spec does not)
other communities I'm in use unofficial face lines f 0//0 1//1
and points f 2//2
gotta love how industry standards have poor support for OpenGL :D
(this is why so many model formats exist and the only ones that actually fully support OpenGL are either disgusting like DAE, or are corporate project formats like FBX, and even then it's a toss-up, as custom game console formats like MDL0/BRMDL support even more than any of them.)
yes I just tested with the old code, and the visual improvement is MUCH better with much less clipping to actually be tolerable, and you can actually see the chunk lines now:
though as a consequence, if you zoom in and step into another chunk, you can see the chunk lines change scale...
not a big deal though as there's not too much change to be seen.
I actually wasn't home yesterday to be able to research the particle system, so I'm doing that now
trust me, with how obnoxiously large the model is (5x5 chunks), I doubt anyone else wouldn't be annoyed with it getting in the way of their work ;)
I'm still bummed it had to actually be a model and couldn't be just a bunch of textured lines...
hopefully fixes are done soon so I can fix this >_>
looking at the C++ src for minetest
it appears you're not able to apply a mesh to a particle...
I could've displayed a particle for 1/9 of a second, while updating the display every 1/10 of a second
I wanted some overlap so the model didn't disappear for a frame...
but that aside, something I can do is spawn a particle for each quad, which I'm obviously not going to do, as I doubt the CPU can draw ~900 quads through a particle engine in LUA, let alone in C per frame, even if it is just for 1 player...
that said it's all server sided so the spawn calls go out per player...
I guess from this point I either delay my release and wait for minetest to support per-player entities
or release my mod as is (everything works decently) and tell everyone to deal with it cause I can't currently make it function like Minecraft
... dangit, I'm bummed and P'd >.<
or as a 3rd option, everyone just use your simple mod for now just so people can HAVE a grid to follow if not to have mine...
just realized images weren't displaying at all for you guys (cached for me)
sorry about that, I guess I was wrong about network saturation >.>
I'll try to keep my daemon running more often...
wish network namespaces were easy to set up and didn't error out so I could actually HAVE a 24h server.