The pile is already high, they’ll never get to the useful stuff if they get hung up on piddly little niggles like these.
3 Likes
Well, it’s not like they all can work on greasy internals. But it does perplex me a bit as well: it’s not like the known issues list or the papercuts list is getting any shorter either. Feels like the opposite, actually.
1 Like
It is an obvious inconsistency. Getting rid of those helps a lot, often also for future development. If there is one well defined way, you are avoiding future discussion about how it has to be done. If it is not clear, be assured several people are going to be confused about it, will look in different areas in the code and will be even more confused. This leads to avoidable discussions among the developers, … .
If the goal is to have maintainable code, that sort of task is very important, whether you like it or not. It can also happen that developers understand it differently and use it slightly different, which makes things more and more inconsistent. When you find something like that, it is best to clean it up as soon as possible, even if it has been around for a long time.
15 Likes
Notes
Cycles
- Intel OpenCL: still blocked by Brecht making regression tests work with OpenCL to validate this is working correctly. Hopefully will be working soon. Afterwards it’s also planned to get this testing running automated for Blender builds.
- AMD driver update: a new driver was released which has been confirmed to fix issues with Radeon RX 5000 series cards, as well as volume rendering on other cards. There still appears to be an issue with baking. We need to go through the many reports about this and asses exactly which bugs are still valid.
- Standalone repository: Stefan asked about when this is updated and who does it. Currently Brecht updates it after every Blender release. It would be helpful to document this, and also have more clear tagging and version numbers indicating a correspondence to Blender releases.
- Optix CPU + GPU rendering: Patrick wants to start working on this. Will need support for building multiple BVHs so both Optix and Embree BVHs can be built at the same time. This should also benefit other GPU devices. Lukas was also going to look into this, Patrick checks with him to avoid duplicate work.
Eevee & Viewport
- The workboard was updated to show the plans for 2.92.
- For Eevee, the plans are to work on AOVs, Cryptomatte, and depth of field.
- For the Vulkan port, the rough schedule has been pushed back one release. This is to make time for improving the Python GPU module to be a more complete replacement for BGL, which has to be deprecated and will stop working once Vulkan is used. The Python GPU module is the current focus of the Vulkan project. Brecht mentions that this will need an organized effort to gather feedback from add-on developers, to ensure the API is complete enough.
Point Clouds
- The geometry nodes project is planning to expose the point cloud object type in Blender 2.92. For this we need renderers to also support rendering it.
- For Cycles, Brecht already planned to work on this for 2.92.
- For Eevee, there is already some support but each point is rendered as a low res sphere, which doesn’t look great. Brecht would like to have a brainstorm session with Clément and Jeroen about improving this, perhaps fake rounded normals without accurate Z depth in the fragment shader is better in practice? To be discussed.
10 Likes
For Eevee, the plans are to work on AOVs
Sigh, OSL still laking this feature and Eevee will get it first… why??? ((
Because EEVEE also means viewport.
And according to roadmap, work on viewport compositor should start in first quarter of 2021.
It looks like some work was already done.
https://developer.blender.org/D7010
But OSL support is listed as one of expected ToDo around AOVs improvements.
I don’t really understand why rendering of points of Point Clouds object is a subject.
Geometry nodes are using point clouds object to scatter instances of objects that are currently perfectly rendered by EEVEE and Cycles.
Nobody really cares about display of points of point clouds objects.
Users may want to have more customization for viewport display to obtain something similar to particles display.
But nobody cares to render points that can be colored.
If we could import .ply files as colored point clouds, we would like to render them with EEVEE or Cycles.
But that is not the case.
To me, it is more important to give orientations to points of a point cloud in order to be able to orient instances of other objects that are already rendered.
Variations of point properties are a must-have to deliver productions with Geometry Nodes.
2 Likes
Cause OSL is basically abandoned/orphaned in cycles. It gets maintained (bugfixing), but that is all (unless some volunteer would pop out of nowhere to work on it) (source).
greetings, Kologe
It`s a pity // OSL still the best choice for heavy and “smart” materials, many aspects of it simply can not be reproduced in nodes
1 Like
There is a limited amount of Cycles developers and they have lots of subjects to treat.
If you take a look to Render & Cycles workboard, you can see that same people have to deal with support or reviews of patchs about Embree, OIDN, Optix, VDB, OpenSubdiv, OpenEXR…
The fact that Brecht specifies that help is welcomed, does not mean that OSL is abandoned.
Minimal version of OSL compatible with current Cycles is not even 2 years old.
Default one has 7 months. And supported features should work with last one.
Sincerely, there are areas of Cycles like Baking that are waiting for improvements since a longer period of time.
2 Likes
Is OSL the only alternative? Is it possible to have something gpu-based like Shadertoy inside Blender or it’s too complex?
It would be cool a way to convert nodes to code (or code to nodes). Or maybe new nodes where you can just put code in (like functions or simple math operations, like osl but gpu/vulkan). Easy say than done, wish I were a dev 
Yes, I know. Sorry, I didn’t mean to sound so harsh or unappreciative. I suppose it’s just that I see it as IPv6 does. I remember when I first looked into OSL, and started to imagine a buch of cool stuff I might do with it, to later realize how some thereof would not be possible in cycles (for the latter doesn’t support a number of OSL-features).
I’m sorry, I’m not following you here. Could you rephrase that paragraph?
Yes, true. One could argue in this specific case (baking) it’s probably interdependent with not strictly cycles-related designs etc. (e.g. the overhaul of blenders baking-workflow), which may be part of the reasons.
Anyway, I personally get the impression, much work in the cycles module is geared towards the performance-topic (optix, cpu+gpu, tilestealing, adaptive sampling, denoising). Maybe this is part of the reason why some other (non-performance-related) stuff seems to be more of a non-priority.
Possible it is quite likely. But (without any inside-info) I’m quite sure such a scenario is even much more unlikely (in practise) than future full OSL-support for cycles.
The reason is simple: Such a new system woud have to either replace OSL alltogether or would mean to add a yet another render-kernel to cycles (in other words tons of extra work for the devs).
greetings, Kologe
(edited for clarity)
3 Likes
I just meant that version of language library was kept up-to-date.
So, in case, there is a little bit. A part of novelty that would be only OSL specific, due to OSL developers, should be exploitable.
“colored point clouds” <- This totally gives it away: Probably refering to better Photogrametry (and point cloud scientific data calculation driven by actual data of their simulations) in Blender.
3 Likes
Arent particles just complex point clouds? If that is so, then point clouds should be a byproduct of particles nodes.
2 Likes
That’s true. I do find it a bit odd that they’re working on colored point clouds specifically instead of just generally point cloud attributes. After all, besides color, you may want attributes for scale, orientation, velocity, mass, whatever. They probably have a reason, but I can’t think of what that might be.
Maybe color is generic enough while the other attributes need to be made in some way that they fit to the final particle node system or something like that.
Do anybody here knows the word “photogrammetry”? 
Jokes apart, the absolute base (as of “basic of basics”) for photogrammetry support is the point cloud and the color attributes. Any open point cloud format consist of a series of x,y,z componenents of a point and an R,G,B color attribute, and only propietary ones adds normals to points. From that is possible to reconstruct geometry using several techniques. Scale, orientation, velocity, mass, whatever (sorry for the C/P Piotr 
) are totally irrelevant in the point cloud world, but i can also perfectly see what artists see when they see “cloud points”,so yeah, all of these are nice to have, but you need the absolute base well done first, otherwise, you’ll get a “bmesh” recode case style again in Blender, and i think nobody wants that again
Of course. That is why I said particles were complex point clouds. Particles are what point clouds are just with more attributes. So if you make a particle system, like for example particles nodes, you get point clouds for free.
Yeah I know all that, but you know, a point with color is just three floats for position, and three floats for color. Why not add support for however many floats the artist wants? 
Should be for the artist to decide what particular (no pun intended) floats mean.
It’s the same with image formats. They all have either one, three of four channels, even the ones designed for textures. It makes no sense that nobody has devised a texture format that compresses nicely and has an arbitrary number of channels to store all your diffuse, normals, alphas, AOs, whatever in a single file.
For the viewport, not exactly , also Point cloud are by definition static, so much data from particles would made a nice waste of ram/vram resources (think of small size point clouds of 300-400 millions of points, i usually get to work with point clouds of 2-3 billion of raw points in LIDAR work, for medium size buildings). (how much floating point data you need for these, i leave that to you :P)
Of course, artists wants to do so much things with these, but probably you’ll want to make sure they fit in your vram/ram to do anything with these first. You really don’t want to be limited in performance as in edit mode, do you?
1 Like