Hi, author here. Just a reminder that we don't use OpenGL, and that it's not skeuomorphism if you don't have virtual screws :)
PBR for Audio Software Interfaces (2016)
31–35 of 35 posts
Re: PBR for Audio Software Interfaces (2016)
#32Obligatory OT comment complaining about the site: I think this is one of the worst performing sites I have ever visited. When the gears in the top right are visible, my whole phone (oneplus one) stutters and when I scroll down, it takes up to a second for the page to follow and render in. I understand the need to make your site special, but if it's at the the cost of this much performance you should really overthink…
Good point, I will perhaps remove it. On my phone tests if was okay.
Re: PBR for Audio Software Interfaces (2016)
#33So, now an audio plugin system has a physically based graphics rendering engine using OpenGL - in order to save diskspace by eliminating pictures of KNOBS ? Am I the only person who considers this beyond idiotic? So now the audio processing machine doesn't need only a powerful CPU for audio but also a good GPU with good OpenGL drivers so that a plugin (not even the main application, but a plugin!) can draw its knobs?…
1. Dplug is using software rendering not OpenGL. Get your facts straight before "calling out" people on the Internet. So the OpenGL driver doesn't matter in any way. By the way, many audio plugins now use OpenGL, just not those. 2. Do you think it's normal an audio plugins would weight more than 100mb of graphics, including memory? No, that's why Dplug uses rendering (in part). It uses less memory space AND installat…
Re 1) Mea culpa - I saw the OpenGL part in the article and didn't read it carefully.
Re 2) Do you find it normal that an audio plugin now spends more time rendering its UI using a CPU renderer than processing audio? That physically based rendering, normal maps and what not are not free lunch!
Yes, 100MB disk space is a lot, but why to have that silly skeuomorphic UI in the first place? Drop it and you won't need those 100MB of textures.
Or do you believe that the user is so dumb that they won't recognize a knob from a button unless it is shiny, knurled and properly lit?
Re 3) This is not about being polite but about calling poor engineering decision out for what it is. So I am standing behind my comment.
Re 4) " We are not after photo-realism. Instead natural lighting effect can help getting into a software by making logical groups and also convey value. "
So not after photo realism but speaking about "natural lighting effect". Isn't that a bit of a contradiction?
And what value is being conveyed exactly? That I am getting a piece of nice, heavy, solid brushed metal? I am not a musician but the ones I know are pretty much all loathing this kind of stuff because it is only consuming loads of resources for no reason and in most cases makes the tools more difficult to use. It is a sound plugin, for heaven's sake, not something to exhibit in a vitrine!
Re 5) Well, you don't use OpenGL, correct. My mistake. However, you have reinvented the wheel using software rendering instead, which isn't even hardware accelerated. Not sure what is worse.
There is also no "hate speech" to drop. Hate speech has a fairly specific definition. Criticism is not hate speech, thank you.
Re: PBR for Audio Software Interfaces (2016)
#34Earlier quoted context omitted.
1. Dplug is using software rendering not OpenGL. Get your facts straight before "calling out" people on the Internet. So the OpenGL driver doesn't matter in any way. By the way, many audio plugins now use OpenGL, just not those. 2. Do you think it's normal an audio plugins would weight more than 100mb of graphics, including memory? No, that's why Dplug uses rendering (in part). It uses less memory space AND installat…
Re 1) Mea culpa - I saw the OpenGL part in the article and didn't read it carefully. Re 2) Do you find it normal that an audio plugin now spends more time rendering its UI using a CPU renderer than processing audio? That physically based rendering, normal maps and what not are not free lunch! Yes, 100MB disk space is a lot, but why to have that silly skeuomorphic UI in the first place? Drop it and you won't need thos…
[deleted]
Re: PBR for Audio Software Interfaces (2016)
#35Earlier quoted context omitted.
1. Dplug is using software rendering not OpenGL. Get your facts straight before "calling out" people on the Internet. So the OpenGL driver doesn't matter in any way. By the way, many audio plugins now use OpenGL, just not those. 2. Do you think it's normal an audio plugins would weight more than 100mb of graphics, including memory? No, that's why Dplug uses rendering (in part). It uses less memory space AND installat…
Re 1) Mea culpa - I saw the OpenGL part in the article and didn't read it carefully. Re 2) Do you find it normal that an audio plugin now spends more time rendering its UI using a CPU renderer than processing audio? That physically based rendering, normal maps and what not are not free lunch! Yes, 100MB disk space is a lot, but why to have that silly skeuomorphic UI in the first place? Drop it and you won't need thos…
I had written another long reply but I felt like it added nothing to the discussion and removed it.
I'd like to adress only the technical issue of CPU usage, in which you are a bit right and perhaps we could agree. Software rendering need to be fast too as you guessed.
The optimizations performed is that only subparts of touched elements are redrawn in intermediate buffers (widgets receive the order to redraw in subrects of their positions), mipmapping (SSE2) is used to help with glow and shadows, tiling and multithreading are used, and the output of PBR is cached. For realtime feedback like spectrograms, the system has a bypass channel in which case the lighting calculation is just a copy. This is what is used for realtime feedback at 60fps, no PBR is computed then. That still leaves big PBR widgets which can be invalidated at once.
It's still not at the level of quickness I wan't it to be (Issue #127), you may have the problem that while turning a big knob - in which caching doesn't help - Crackles may occur. I'm pretty confident it can be solved completely when #127 is fixed and lighting is more SIMD and less shader-like.
So it's an ongoing process of making this rendering faster, however the rewards in my opinion are numerous (and there we get in debatable material so I won't disgress).