mosra/magnum

Lightweight and modular C++11/C++14 graphics middleware for games and dataviz

Thomas Tong

@thomastong

To do our own overdraw rejection, before it hits the driver?

Vladimír Vondruš

@mosra

not really, you'd need to go with mesh shaders, which are nvidia-specific, and do culling there

in the classic vertex pipeline there is no way to discard parts of the mesh

Thomas Tong

@thomastong

i see, by the time it gets to the shader, it's already too late :(

Vladimír Vondruš

@mosra

but meshoptimizer should help with reordering the buffers for better memory cache efficiency and also for reduced overdraw (basically you get contiguous patches rendered which means a lot can get discarded by early depth tests compared to rendering really random points)

though that will of course also interfere with your acceleration / LOD structures, so you'll need to find some tradeoff between the two

Thomas Tong

@thomastong

i will try it out later today and let you know how it goes. Thanks so much for the help so far. As a side note, does anyone have suggestions for a fast normal estimation function? We're using the one in Open3D and it's taking about 3 minutes with large point clouds, and 15 minutes in debug mode :(

normal estimate for point clouds i mean.

Vladimír Vondruš

@mosra

hah i was just thinking if you could avoid having the normal attribute somehow :)

what is the perf difference between flat and phong shader? is it significant to be worth pursuing further?

i suppose if you'd feed only positions to the shader without the other attribs you could get some speedup

Thomas Tong

@thomastong

the point cloud is not really viewable with the flat shader. -

Vladimír Vondruš

@mosra

yeah i know, it's just a shadeless blob

Thomas Tong

@thomastong

I think in order to use the flat shader, I was thking of writing a new shader can would do some psudo-lighting.

Cause currently the flat shader is near useless and a phongshader is too rich

Vladimír Vondruš

@mosra

yeah exactly, render with a flat shader to get the depth, and then do normal (and lighting) reconstruction from the depth buffer

Thomas Tong

@thomastong

it would be nice to have something in between that's much faster than the phong shader, but still provided some sort of useful information.

Vladimír Vondruš

@mosra

there's some optimization potential in the phong shader, it's doing certain things in an unnecessarily complicated way ... i just didn't have an opportunity to look at it in depth yet

do normal (and lighting) reconstruction from the depth buffer

but this looks much more suited for the point clouds, because compared to plain triangle meshes you really have normal information for almost every pixel

Thomas Tong

@thomastong

With directx 9 pipeline (our old gfx engine) if you turned off specular lights, it was much faster at rendering, but you still got the diffuse term, it was a 30- 40% faster than with lights on.

Vladimír Vondruš

@mosra

ah good idea, you could try commenting out that part

Thomas Tong

@thomastong

Currently i think magnum phong rendering is currently on par with our old DX engine, so am happy about that. :D

Well you've given me some ideas... I guess, i would need to make a copy of the shader, and make a phong shader with no specular :D

Vladimír Vondruš

@mosra

https://github.com/mosra/magnum/blob/af7c1f1b07bfc8985e2b4b5188a6a27b935b8ab6/src/Magnum/Shaders/Phong.frag#L280-L286 if it makes a difference without this, i can add a flag there

ah i thought you have magnum as a submodule or something similarly easy to change

btw in the screenshots i saw some Unicode issues in the console (with "µs"), are you linking to Corrade::Main?

Thomas Tong

@thomastong

no completely different products unfortunately, it's a bit of a pain to pull metrics to do comparison.

I don't think Corrade::Main is being linked in, i believce the way it's setup is Via Magnum SDLApplication and the majority of the code is in a DLL.

And it was made so it could be called by SDL Application or a WPF application ...

and it seems to be working but the WPF / other stuff container is not quite maintained...

Vladimír Vondruš

@mosra

ah okay :) i was wondering how you managed to get colors in the console but not unicode :) docs for the lib: https://doc.magnum.graphics/corrade/main.html

linking to the lib should make it so that the console output is set to UTF-8, but if you have WPF there as well, I fear the two won't cooperate :sweat_smile:

Thomas Tong

@thomastong

I think it's something easy to fix, but it's someone elses problem and I don't have time to dive in to this stuff on weekends

Vladimír Vondruš

@mosra

yeah it's just one winapi call, and it works well enough without, so ¯\_(ツ)_/¯

Thomas Tong

@thomastong

I think someone wanted to make it so what we could attach to WPF, blazor, or whatever other GUI stuff was out there.. there was some dreams and hopes but currently it's all SDL app... so.. losing out on the Unicode in the console is well, pretty much a E bug lol

i will look in to it though.. :D

Vladimír Vondruš

@mosra

https://github.com/mosra/corrade/blob/6054f1b1d3f768afc226bb0f633b8216283e2158/src/Corrade/CorradeMain.cpp#L103 is the magic api

i gotta go, 11 PM here :wave:

Thomas Tong

@thomastong

gg thanks for the hlpe

btw: made the call

fixed !

Vladimír Vondruš

@mosra

for the normal estimation, https://doc.magnum.graphics/magnum/namespaceMagnum_1_1MeshTools.html#acec1aa76831e1caad2d5d486be60f575 but it's just for triangle meshes and not extremely fast either (i need to properly SIMD the thing)

Thomas Tong

@thomastong

Okay, -- been mulling over this and I my theory now is that on the physical card, that specific portions of the pixels are the screen are allocated to specific processing units, - i haven't kept up with GPU architecture, or shaders so I don't know the technical terms

but as i zoom out, instead of the point cloud data being drawn to be processed by my whole video card, as I zoom out, and everything is stacked on to a 100x 100 pixel block, i end up only using like 15% of the video card for all the points while the rest of the processing units are simply clearing to black...

Innokentiy Alaytsev

@Innokentiy-Alaytsev

Maybe some space subdivision and culling with a compute shader?

android_daw

@android_daw:matrix.org

[m]

:point_up: Edit: I am getting

undefined reference to `streamDebug'

when linking to Corrade:: on android

however it successuflly links when building and linking on MacOS

https://github.com/mgood7123/AndroidCircularBuffer

need to symlink src/main/cpp/CircularBuffer/java/smallville7123/circularbuffer to src/main/java/smallville7123/circularbuffer

android_daw

@android_daw:matrix.org

[m]

:point_up: Edit: I am getting

undefined reference to `streamDebug'

when linking to Corrade:: on android

however it successuflly links when building and linking on MacOS

https://github.com/mgood7123/AndroidCircularBuffer

need to symlink src/main/cpp/CircularBuffer/java/smallville7123/circularbuffer to src/main/java/smallville7123/circularbuffer

this is the full build output in android studio

https://gist.github.com/8aace33cac3cabdff75ae9613d0c93c3

and this is the full build output in MacOS

https://gist.github.com/mgood7123/84b76a58038b7f272a09760dc2a88ed5

Vladimír Vondruš

@mosra

@android_daw:matrix.org this is a problem with your code, not mine, this has nothing to do with corrade

1 reply

Vladimír Vondruš

@mosra

@thomastong it's just a lot of fragment shader invocations competing on a single depth buffer pixel as pezcode mentioned initially (which needs to get depth tested because you have a depth test enabled)... you can think of it like this:

if you have 1000 points scattered across the screen, the fragment shader invocations can be executed and depth tested in parallel as they don't depend on each other in any way
but if you zoom out and suddenly have those 1000 points covering just a single pixel, then the fragment shader invocations need to get executed sequentially -- testing first against the current depth value in the buffer, writing it if it's less, testing the second against the value written by the first etc, and that's where the massive perf difference happens (you could try disabling the depth test and maybe that improves the performance at the cost of a wrong result but maybe also not, since there's still a lot of overlapping color writes)

and then, if you have a triangle mesh instead of a point mesh, 90% of these triangles get discarded because they're so small that they wouldn't contribute anything visible to the pixel anyway

Where communities thrive

People

Repo info

Activity