Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 00:24
    codecov[bot] commented #114
  • 00:23
    codecov[bot] commented #114
  • Mar 07 22:06
    celentes commented #114
  • Mar 07 21:52
    celentes synchronize #114
  • Mar 07 21:48
    mosra commented #114
  • Mar 07 21:14
    celentes opened #114
  • Mar 07 21:13

    mosra on next

    Deprecate the weird Magnum::Arr… doc: oops. Vk: doc++ and 1 more (compare)

  • Mar 07 20:30
    mosra edited #146
  • Mar 07 13:25
    Rabios starred mosra/flextgl
  • Mar 06 22:08
    mosra edited #306
  • Mar 06 22:04

    mosra on next

    doc: put this changelog entry i… Trade: TextureData constructor … No need to have explicitly writ… and 2 more (compare)

  • Mar 06 15:36

    mosra on next

    package: temporarily disable tr… (compare)

  • Mar 06 13:55
  • Mar 06 13:32
    mosra edited #306
  • Mar 06 12:24
    mosra edited #306
  • Mar 06 11:56
    mosra edited #306
  • Mar 06 11:33
    mosra edited #306
  • Mar 06 11:31
    mosra edited #306
  • Mar 06 09:59
    mosra edited #453
  • Mar 06 09:57
    mosra edited #453
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
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
:D
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