how would I draw a 3D line on a formspec?

[Tcll]

for a better description of what I'm trying to do
I'm working on a mod that should be capable of drawing this:


I can't recall a time when I haven't used this mod in Minecraft, and now that I'm on Minetest, I'm really missing it
it's really annoying to have to rely on the wonky animations of lava lakes to align my chunk builds...

[v-rob]

ATM, real line drawing in formspecs is impossible; 3D lines even more so. The best you can do is use a diagonal line image.

I don't see why you want to use a formspec for this, though. Entities are much more suited for this. See worldedit for an example.

[Tcll]

formspec because I want it to be a toggle that only I can see, just like the mod
it's been a while since I made Minecraft modpacks (local only), but I think it was either Random Things or OpenBlocks that did what's in image (toggle with F7)...
and then of course we also have Minecraft 1.10+ which has it's own version of this (yellow and blue lines with added vertical chunk mapping, toggle with F9)

plus nodes are kinda a hassle to work with as it needs to move with the player much like wielded light, except for more than just air nodes
unless I can place 2 nodes in the same space and not have to worry about 2nd-player interaction with it >_>
I could just make the node not display it's mesh for non-associate players if that's the case

at best though I could probably just make a B3D of nothing but shadeless red lines (square tubes) for the chunk model
and then model a bunch of green lines for the node model to make it behave similarly

I plan to use red dots (shadeless squares) between nodes for the vertical chunk layout though
maybe an extra red line for the middle of the 2 vertical chunks you're between

[GreenXenith]

Entities are the optimal solution for this, as v-rob has already pointed out. WorldEdit and protector_redo both have similar region markers. Yes, everyone can see the entity, but that isn't a terribly huge issue. There was a PR to implement per-player entities at one point, I don't know what happened to it.

Another alternative using current available methods: Use HUD waypoints. Waypoints support non-coordinates and images now, so it would be trivial to mark the corners of chunks. And its per-player.

An alternative when #9079 is merged would be a command to toggle a custom chunk-image for the minimap.

There are a few other less-optimal alternatives (nodes, other HUD elements, etc), but using formspecs is not a good idea. Especially since you have to open and close it to see your markers and build.

[Tcll]

oh wait, woops
idk how I confused "entity" with "node", but I absolutely did x.x

yeah entities would be a great solution as they can be made visible per player with some work, and aren't affected by most callbacks or physics unless programmed otherwise
thanks for the skull knock, I needed that

but anyways, I thought formspec was always running >.>
I guess I've still got a bit to learn about that... heh

waypoints are an idea, but unless I can draw models, that's a big no
reason for that is I only need 3 model sources

EDIT:
btw, what's the scale of models in blender compared to minetest??
like is (1.0,1.0,1.0) in blender the same coord in minetest??

[v-rob]

Models have to be (10, 10, 10) to be the equivalent of a Minetest node as far as I remember. Either that, or set the visual scale to 10 and make the object (1, 1, 1) in Blender. You could also use four "upright_sprite" entities.

Formspecs are any menu, e.g. the player inventory, a chest or furnace, etc. You can't move around while they're open.

[Tcll]

ah alright, thanks
I'll probably take the visual scale approach as that seems easier to manage mentally

and yeah, I understand what you mean by only using 4 faces
but the problem I have with that is viewing angles...
that's probably just me though, there's cheap, and then there's too cheap :P

I'm not going all out with square tubes though
I'm only drawing what you'd actually see
like for example the red corners are only 2 quads each
the green lines are 3 quads at eye level, but 2 quads for everything else
and the dots at the top and bottom are just squares

sure it's a bit more than 8 vertices
but if the engine can handle extruded textures well, then it shouldn't have a problem with what I'm doing ;)
or in other words, any PC capable of running Minetest above 16 FPS shouldn't have a problem with my mod

EDIT:
if you (or another reader) still don't have confidence in me
I run a GT 430 in 2020 and I'm telling you it's a non-issue ;)
if you can beat me as the worst computer of 2020, I'll show you some attention
as I have yet to see someone who isn't a boomer with a PC worse than any of mine ;)
and don't cheat with a raspberry pi, though in all honesty, even that can probably beat my development rig XD

no I'm not complaining, I'm just trying to say I probably have the worst PC of this entire forum,
so if anyone's concerned with the performance of any of my mods, don't be, my mods will likely run much better for you than they will for me ;)
(and I'm aiming for good performance on my cruddy machines)

[Tcll]

that moment when you realize Minetest's node alignment is pure toxicity (pos+0.5)

you're not supposed to be able to see this side of the mesh x.x

buuut at least I got the alignment proper for what it does:

I just need to compensate to make it update appropriately x.x

among a few other issues, such as how the grid looks 3D when it's not supposed to...
though tbh I might make this a setting if I figure out how to fix it cause I do kinda like it :P

EDIT:
btw, if you can't see the images, you either don't have IPFS, or my node isn't running...
(the files have finally saturated the network, my node is no longer needed)

EDIT2:
well before I go to bed, I want to mention I'd fixed the issue (mostly) with being able to see behind the grid
there's still a very small area you have to work to so you can see behind it, but for the most part it flips appropriately.

but aside from that, I've pretty much gotten everything else complete and just about ready for an initial mod release/thread
literally the only thing I have to do is re-learn how to set visibility for specific players viewing the same entity...
if anyone knows how and wants to fill be in while I'm afk, feel free :)
otherwise I'll figure it out throughout the day tomorrow :P

I've also taken screenshots of a few themes I've worked on
buuuuuut my USB ports decided to perma-nope because someone decided usbcore.autosuspend was a good idea
so I can't transfer them to post here until I restart and patch that out of my kernel... gotta love linux amiright :D
(wouldn't have it any other way though, unless there's something better)

EDIT3:
ok, now that my USB ports work, here's a very minor CDPR move: :)
MC110


blueprint


I have more themes than this, you'll have to actually use my mod to see them ;)

and to those who are oddly concerned about cheating, no this doesn't help you see in caves other than from falling off an edge...
honestly, I don't see anything wrong with low level daylight in caves as it's NOT cheating...
tbh I miss the feel already and wish I could enable it on my local server...

the option should at least be provided for those who for some reason feel it is cheating.
(yes you can see ore in dark caves, so what, it's not like there's actually a game to protect where this would harm anything, even if mobs were a thing)
^ at least Minecraft has a story, which even then "cheating" is not actually cheating (wood, flint, string, and feathers is more powerful than diamonds)

if I wanted to "cheat", I'd make a mod that disabled lighting (Minecraft's night vision) to where caves were fully lit everywhere I went.
(which actually does have use like Aroma1997s Dimensional Wold, aka the mining world, where server owners can reset this world to avoid destruction of the overworld)

so again, I really don't understand why caves absolutely HAVE to be pitch black like the world depends on it.

EDIT4:
oh HAHA, I just realized QasMixer photo-bombed my shots XD
ah well, not like the fact I don't use audio servers like Pulse or Jack actually harms anything.

[Tcll]

and of course, the duck is letting me down again...

I can't seem to find any information for detecting the current player/client from an entity...
I could've sworn I'd seen a reference before, or maybe I'm just hallucinating... idk

if anyone knows, could you please provide, otherwise everyone gets to see everyone's grid...

EDIT:
just tried minetest.get_player_by_name() and as expected, that doesn't work as there's no option for nil when you don't know what player you're on...

EDIT2:
dangit, I can't find any way to get the current player or even the client...

all I need is simply some way to do this and I'll be able to make an initial release:

Code: Select all

on_step = function( entity, dtime, collision )
    local props = { is_visible = false }
    local playername = entity.playername -- set on player join
    local player = minetest.get_player_by_name()
    if playername == player:get_player_name() then
        if minetest.get_player_information(playername) then -- player is online
            ...
            local meta = player.get_meta and player.get_meta()  -- version compat sucks (should be universal)
            props.is_visible = tobool((meta.get_string or player.get_attribute)(meta or player, 'enabled') or 'false')
        else entity.object:remove(); return end
    end
    entity.object:setproperties(props)
end

not sure what's so difficult about designing a universal API, but whatever... (yes I have experience)

if minetest.get_player_by_name() worked as expected in this case, it would return the current player
not sure where the actual execution takes place, but it can work from both sides:
client: returns local player
server: sends a CSM response to the individual entities on each client with associated data (non-iterative) where the local entity holds the local player returned.

I hope my CSM understanding is roughly correct anyways, because so far everything seems server-sided

[GreenXenith]

I am rather confused at this point, but I will take a shot at helping you anyway.

First of all, the center of a Minetest node is on X + 0, Y + 0.5, Z + 0. There are various reasons for this, but it shouldn't matter all that much if you are doing things properly.

From what it looks like, you are using individual faces for all of your grid lines. You should instead be using a single plane with a texture. It will look better and perform better.

No, you do not have the worst PC setup, I can 100% guarantee that. I know a Minetest user that plays Minetest with no shaders, minimal settings, subsampling of 8, and he still only gets 5-8FPS.

not sure what's so difficult about designing a universal API, but whatever... (yes I have experience)

"Universal API" is a nonsensical term. If you design a 100% backwards-compatible API, you end up with something like Windows. If you really want to support outdated versions, it is trivial to make compatibility layers.
From your code snippet, you are also using meta methods incorrectly.
player:get_meta():get_bool("modname:visible", false)

This is where my understanding starts to fail, because I'm not sure what exactly you are trying to do. From what I can tell, you want one of these entities to be linked to every player or something and update with them (presumably to automatically show which mapblock they are in?). To do this, you should spawn the entity in a register_on_joinplayer, and despawn it in a register_on_leaveplayer. That way the player definitely exists when you need it to. You can add a key to the entity to reference the player object or name (object reference is faster, as long as you handle it properly). Then in on_step use if self.player then ... end to do your updating.

Please read the documentation. Do not "expect" functions to do something other than what it is documented to do.
minetest.get_player_by_name(name) will return an object if there is a player found with name matching the provided string, or nil. If it returns nil, the player is not online. The key part of this is you have to provide a playername to the function. That is how most programming languages work. They aren't just going to "know" what you want it to do.

CSM has nothing to do with this, it is not a mature or supported API. Best not to think about it.

[Tcll]

I am rather confused at this point, but I will take a shot at helping you anyway.

yeah sorry about my autism getting a bit out of hand with 15+ topics... I can't control it :P

First of all, the center of a Minetest node is on X + 0, Y + 0.5, Z + 0. There are various reasons for this, but it shouldn't matter all that much if you are doing things properly.

trust me, I have to (floor((xy+.5)/16)*16)-.5 to align it apropriately, which eats performance

From what it looks like, you are using individual faces for all of your grid lines. You should instead be using a single plane with a texture. It will look better and perform better.

actually, you'd probably be surprised ~1300 polygons performs rather well, even on my machine ;)
though I don't disagree with making a low quality version, and actually plan to on the next release.
though for theme compatibility, it'll still be similar to how it's currently set up
with the way it works, each quad gets 1 pixel on the texture

No, you do not have the worst PC setup, I can 100% guarantee that. I know a Minetest user that plays Minetest with no shaders, minimal settings, subsampling of 8, and he still only gets 5-8FPS.

hahaha, alright fair enough XD
glad to know I got beat :)

yeah I'll absolutely do what I can to make the lq model good for them

"Universal API" is a nonsensical term. If you design a 100% backwards-compatible API, you end up with something like Windows. If you really want to support outdated versions, it is trivial to make compatibility layers.
From your code snippet, you are also using meta methods incorrectly.

I uhh... disagree, but only because I'm a 1-man army when it comes to my API :P
abstractions for compatibility reduce performance (especially on a frontend) and needlessly increase the code base

and what I did for the method is separate self so it's simpler to use than having to do meta:get_string vs player:get_attribute

This is where my understanding starts to fail, because I'm not sure what exactly you are trying to do. From what I can tell, you want one of these entities to be linked to every player or something and update with them (presumably to automatically show which mapblock they are in?). To do this, you should spawn the entity in a register_on_joinplayer, and despawn it in a register_on_leaveplayer. That way the player definitely exists when you need it to. You can add a key to the entity to reference the player object or name (object reference is faster, as long as you handle it properly). Then in on_step use if self.player then ... end to do your updating.

yes that's pretty much exactly what I'm doing, except for the leaveplayer bit.

local playername = entity.playername -- set on player join
^ this is exactly that key you mention

the PROBLEM is I can see everyone else's grid

Please read the documentation. Do not "expect" functions to do something other than what it is documented to do.
minetest.get_player_by_name(name) will return an object if there is a player found with name matching the provided string, or nil. If it returns nil, the player is not online. The key part of this is you have to provide a playername to the function. That is how most programming languages work. They aren't just going to "know" what you want it to do.

CSM has nothing to do with this, it is not a mature or supported API. Best not to think about it.

yes I know that's what the function does
it's a shame you can't supply nil to get the current player (or nil if there is no player) whenever referenced.

that's part of the problem with my mod as the entity should only be visible to me.

EDIT:
and regarding the bit about programming languages being unautonomous, you can make them autonomous
I have done this with my API

for example:

Code: Select all

>>> len(CurrentScene.Objects)
0
>>> myobject = CurrentScene.Objects['MyObject']
>>> len(CurrentScene.Objects)
1

that's probably a stupid simple example, but whatever, the point is it automates everything needed to reduce code complexity.

[GreenXenith]

1300 polygons is absurd for an entity like this. Just sayin'.

That alignment operation should not be done very often, so it shouldn't affect performance much. It can also be simplified to {x = math.floor(pos.x / 16), y = math.floor(pos.y / 16), z = math.floor(pos.z / 16)} or vector.apply(pos, function(v) return math.floor(v / 16) end).

In your "autonomous" example you are still providing an object list.
Also, there is no "current" player. That doesn't make sense.

As I already said earlier, if you use an entity, you cannot control who can see them. There is no way around this currently.

[Tcll]

1300 polygons is absurd for an entity like this. Just sayin'.

even I agree with that
and yes I will be reducing that now that I see exactly what I have to do

That alignment operation should not be done very often, so it shouldn't affect performance much. It can also be simplified to {x = math.floor(pos.x / 16), y = math.floor(pos.y / 16), z = math.floor(pos.z / 16)} or vector.apply(pos, function(v) return math.floor(v / 16) end).

yeah, once I re-align and upscale the blender models I can apply it like that (and intend to)
#minorannoyances

In your "autonomous" example you are still providing an object list.
Also, there is no "current" player. That doesn't make sense.

I mean, yes, through the meta of the default scene creation, the properties automatically create the default objects for the scene's attributes...
but as for the current bit, there's actually the current object in my example code:

Code: Select all

>>> myobject = CurrentScene.Objects['MyObject']
>>> myobject == CurrentObject == CurrentScene.Objects.current
True

I have a ton of dynamics going on to achieve that, but at the same time it's purpose is for model conversion
speed is only the secondary focus there >_>

as for how this would apply to minetest if implemented
the server has to iterate over it's connected clients, so the current player there would be whatever is currently iterated
otherwise within the client the current player would always be the local player object

As I already said earlier, if you use an entity, you cannot control who can see them. There is no way around this currently.

>.>
I must've overlooked or forgot about this... sorry about that.

[GreenXenith]

"Current player" would only apply to the CSM API. This modding is server-side, therefore there is no current player. There is also no "currently iterated player".

Anyway, if you really care about per-player visibility, it has occurred to me that particles would also work. It would require some extra handling to spawn and keep track of them, but it does provide the effect you want.

[Tcll]

the server I'm connected to has to update the entities on my screen somehow
that's where you'd get the current player data from that could be used to disable entity visibility ;)

but anyways, alright, I'll look into that, thank you

[Krock]

Per-player entity visibility does not exist yet, but has been requested: https://github.com/minetest/minetest/issues/8045

Alternatively, you could also use the "cube" entity visual and use textures to show the grid. This does not cause any distortions in rendering but results in not-so-nice upscaling and the shape of a cube (unless scale is adjusted manually).

Example of a 2x2 px texture: (taken from my simple_protection mod, largely based on the landrush mod)

[Tcll]

oh interesting, that would be a simpler way to do this

the issue I have with textures though is the flat view when you're close to the sides
which is exactly why I'm using a mesh...
though I actually forgot about obj and might switch to it if lines actually work:
f 1//1 2//2 (no normals)

I've actually been optimizing my blender meshes for B3D to have less vertices, since that's ultimately what boggs down your GPU
polygons do too, but not as much as vertices... at least depending on your GPU

also @GreenXenith, I was a bit wrong when I said scaling the blender mesh would move it by 16
x = math.floor(pos.x / 16) will always move x by 1 node unless there's a way I'm unaware of to make it move by 16 without x = math.floor(pos.x / 16)*16

EDIT:
well crap
obj lines only export under
l 1 2
no theme support other than materials x.x

EDIT2:
well, minetest doesn't seem to support lines there...
wonder if it supports f-lines (apparently unofficial despite being commonly used within other communities I'm in) >_>

EDIT3:
nope, that doesn't work either... dangit u.u
... well it was worth the try at least :P

[GreenXenith]

Ah, right, I forgot the 16 multiplier (the floor/16 returns a mapblock position).

I spent an hour and made a mapblock marker mod. 44loc that includes a toggle command. Also has two variants, but I've set it to the thin version in the attachment.
Player pos 0, 16.5, 0:
Player pos -1, 32, -1
Thin version

Uses an OBJ mesh with 6 faces and a single texture. Scaled up very slightly to avoid Z-fighting.
Use /blockmarker to toggle.

blockmarker.zip

(6.05 KiB) Downloaded 11 times

[Tcll]

neat, still very basic compared to mine though, but yeah
I'm using b3d for mine cause if I'm gonna use textured faces there's really not much point to using obj...
the only real reason I was excited for obj is because it supports lines...
but it's pointless if minetest-irrlicht doesn't support lines

as for only having 6 faces, the game is CPU bottle-necked by LUA anyways, so it really doesn't matter
my model may be atrocious with more polygons than I'm comfortable with, but it's still not much to be concerned with
that said though, I do intend to release a low quality revision just for those with lower-grade builds
(I have a 32bit P4 with an 82845G northbridge-GPU if you really need me to worry about performance) ;)
^ I also have a P-III with an 82810E GPU that's no longer supported by Void Linux, and barely supported by Xubuntu 16.04
^ or a P-II/Celeron, but that's getting a bit thick and probably won't run any Linux ISO I have (maybe DSL if that)

but anyways, the reason it's taking me so long is I'm still learning the API, which IMO is atrociously inconsistent and abstract with horrible documentation and lacking support ;)
like for example, I had to find some foreign page to find out get_player_information() can also return nil (not a table) if said player is not found.
if I weren't experienced in general programming, I'd expect it to always return a table like the doc explains.

and then for getting the name of an object you have get_name() vs get_player_name()

basically tons of nit-picking that could be much much simpler and easier to grasp/use if not better explained... :P
give me credit where due, I'm learning, and I give you credit for helping me :)

[GreenXenith]

The main reason to pick B3D over OBJ is because B3D supports rigged animations, but that isn't a concern here, so the only other reason to do so would be file size differences (which are negligible anyway). OBJ is a more widely-used format and has the "bonus" of being human-readable. I'm not sure about the differences in processing (likely also negligible).

The CPU is not bottlenecked by Lua nearly as much as the graphics card is weighed down by thousands of extra polygons. But as long as you keep the mesh under 1k, it shouldn't really be an issue.

Do remember that this is developed and run by volunteers, and is not intended to be completely professional. API documentation is not the first priority. If you see inconsistencies or missing documentation (such as the nil get_player_information return), please open an issue.

Be sure to let us know when you get your mod finished :)

[Tcll]

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.


EDIT:
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.)

EDIT2:
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 >_>

EDIT3:
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...

welp...
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...

EDIT4:
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.