| Time |
Nick |
Message |
| 00:26 |
|
YuGiOhJCJ joined #luanti-dev |
| 04:00 |
|
MTDiscord joined #luanti-dev |
| 04:56 |
MTDiscord |
<herowl> For drawing lines, I'm not sure if that PR was going the right way tbh. It was turning the line into a mesh, and entityfying it in a way. A useful line primitive should have visibly less overhead than an entity and maybe should try and draw a line instead of a bunch of filled polygons. |
| 08:10 |
MTDiscord |
<.zenonseth> yeah, I completely agree, I went theh route of a new LineSAO which is a very lightweight obejct with minimal updates, no user-specified updates, etc. So ofc my first thought was to support line primitives, see https://discord.com/channels/369122544273588224/378685007226470411/1525273039959494829 -- but i was going to add simple polygon support, there's still some merit i think to not having to define them as entities |
| 08:40 |
MTDiscord |
<andrey2470t> My PR used the separate representation of the lines, not as new type of entity, so it didnt entitify |
| 08:45 |
MTDiscord |
<andrey2470t> I think the lines (and any other kind of primitive) could be just drawn directly per a frame and at client-side like the Irrlicht's draw functions (VideoDriver::draw3DLine). Since the primitives are generally assumed to be dynamic, I think it doesn't make sense to objectify them |
| 08:53 |
MTDiscord |
<andrey2470t> Well and also as the lines are very lightweight vertex data and generally they will be spawned rather not so often as entities the direct rendering them instead of VBO will affect insignificantly the overhead and performance |
| 09:00 |
MTDiscord |
<.zenonseth> I'm gonna see if i can make the PR later today, just for non-mesh line drawing. Then there's some discussion to be had if mesh line drawing should be added - I think its worth it because LineSAO/CAO are much simpler objects update wise, sending only 2 points - so using them for pre-made simple line meshes, e.g. 2 quads or even a hex tube - meshes which is not constructed on server but on client side only from those 2 endpoints, is |
| 09:00 |
MTDiscord |
definitely worth it, imho |
| 09:16 |
sfan5 |
IIRC the problem with draw3DLine was that line drawing is basically deprecated in new OpenGL versions and you also don't get much choice about the width of the line |
| 09:18 |
sfan5 |
"direct rendering vs VBO" is a bit of a trap too, because the OpenGL core profile has removed direct rendering. everything you want to render has to be uploaded to a VBO. |
| 09:18 |
sfan5 |
(we're still using the compatibility profile where this is possible. and a bunch of irrlicht code makes use of it.) |
| 09:26 |
MTDiscord |
<.zenonseth> so i based my line rendering on the way particles did it, maybe i can look into extracting that and generelaizing it - but basically having a irr_ptr<scene::SMeshBuffer> m_meshbuffer; and then doing stuff like buf->setPrimitiveType(scene::EPT_LINE_STRIP); //.... for (size_t i = 0; i < points.size(); i++) { video::SColor c = i < props.colors.size() ? props.colors[i] : props.color; |
| 09:26 |
MTDiscord |
vertices.push_back(video::S3DVertex(points[i] - origin, v3f(0, 1, 0), c, v2f(0, 0))); indices.push_back((u16)i); } |
| 09:33 |
sfan5 |
here's what I meant btw https://docs.gl/es2/glLineWidth |
| 09:33 |
sfan5 |
> There is a range of supported line widths. Only width 1 is guaranteed to be supported; others depend on the implementation. |
| 09:33 |
sfan5 |
if we want to give the mods the choice how the line looks then a working implementation can't be built on this |
| 09:42 |
MTDiscord |
<.zenonseth> so that makes sense not much has changed since my days like a decade ago when messing with raw opengl :) That's why I was thinking of adding a "+" shaped "line" and a hex 'tube' line that both can control their 'width' - but will simply send it as another type to client and client can make the actual meshes, so nothing aside from like an extra enum and a field, needs to change on server |
| 10:00 |
MTDiscord |
<andrey2470t> I tried to implement rendering the GUI and HUD elements via VBO somehow half-year ago in my old fork grouping them in separate 2d mesh batches, but how I didn't struggle it gave always generally a lower FPS, especially much the FPS sinking down was caused by updating them like buttons clicking, tabs switching, scrolling. So how I figured out the direct rendering stayed an optimal variant for dynamic graphic things. I think the line |
| 10:00 |
MTDiscord |
rendering is analogous with that |
| 10:02 |
MTDiscord |
<andrey2470t> Possibly it could be optimized by batching in the single VBO, but with the Irrlicht's GUI system it is very not trivial to do |
| 13:37 |
|
lhofhansl joined #luanti-dev |
| 13:51 |
lhofhansl |
Hi all... Planning to merge #17285 in a few. |
| 13:51 |
ShadowBot |
https://github.com/luanti-org/luanti/issues/17285 -- More efficient, approximate, layered server occlusion culling by lhofhansl |
| 14:07 |
lhofhansl |
Done |
| 14:14 |
lhofhansl |
Also had a question w.r.t. folks' experience with the number of mesh_generation_threads. I get better performance out of my (fast) system when that is set to 1, and on top of that jitter is much reduced. If someone is willing to try it out. If I'm not the only one we can default that setting to 1 (or remove it altogether). |
| 14:20 |
|
lhofhansl joined #luanti-dev |
| 14:24 |
|
lhofhansl joined #luanti-dev |
| 16:56 |
MTDiscord |
<.zenonseth> PR for the lines API, still WIP since no support for meshed lines (+ or hex-tube style) yet: https://github.com/luanti-org/luanti/pull/17335 |
| 16:58 |
MTDiscord |
<.zenonseth> this is for the lines stuff we were discussing earlier i mean, how i handled the lines as obejcts, still think its fairly minimal and not as impactful as entities, so the +/hex lines are worth adding |
| 17:46 |
|
crazylad joined #luanti-dev |
| 22:33 |
|
panwolfram joined #luanti-dev |
