I believe the table to be correct about vertex colors, in that it is supported by glTF and OBJ. However, I believe Panda3D will only render vertex colors if there is no diffuse color specified in the material, or if there is no material applied at all. You can remove the material from a model using setMaterialOff(1).
As for the colors appearing different, please see the section “Why do my colors look different?” on the Converting from Blender page.
I’m sorry if I got confused, but this sounds like Assimp offers more features after these changes compared to simple-pbr? Specifically, simple-pbr webpage mentions no support of “IBL Diffuse” and “IBL Specular”
Also it looks like the buildbot link is not available from the website. You might want to link it in the Download page.
Set your textures to use the Texture.F_srgb or Texture.F_srgb_alpha texture format, which automatically linearizes the colors before they are used in the rendering process. This should only be done on color textures, not on other types of texture maps.
Tell Panda3D to ask the graphics driver for an “sRGB framebuffer”, which causes the GPU to automatically convert colors back to sRGB before they are displayed on the monitor. This is achieved by enabling framebuffer-srgb in Config.prc, or by adding a post-processing filter as described in Common Image Filters.
Option 1 does not help with vertex colors and I would assume material colors as well.
Option 2 messes up all the UI art that has been created so far, and I’m not even sure how it would be created to look right in an image editor even if all UI art was recreated from scratch…
A custom image filter seems like an overkill and a band-aid rather than a solution.
Assimp cannot be compared with panda3d-simplepbr, it can only be compared with panda3d-gltf. I don’t know what “IBL Diffuse” and “IBL Specular” refer to specifically.
Assimp, at least our implementation of it, does not support more features than panda3d-gltf. There are a number of features that don’t work (well) through Assimp (morph targets jump to mind) that do work well through panda3d-gltf. Even if there were a feature that Panda supported that we loaded through Assimp, I expect that it would be added in no-time to panda3d-gltf, which is far more widely used than the Assimp loader.
It is possible that our support for glTF through Assimp will improve further in the future, and become more mature, and at that time it will be a viable replacement. And I am happy to entertain bug reports regarding glTF support through Assimp. But I would recommend staying with panda3d-gltf at this point.
I’m aware that the buildbot pages aren’t linked from the download page. At this moment I do not have the time or mind-space to write a WordPress plug-in that can serve up these files.
They are not two separate options, but two things you need to do. In the past (so therefore this is the default in Panda), blending and lighting are done in gamma-corrected sRGB space, which generates incorrect / unrealistic results. At some point, the industry switched over to linearized sRGB, which involves applying the inverse gamma curve to source assets and re-applying the gamma curve to the rendered framebuffer (done in hardware). Blender / glTF 2 assume a linear-space renderer, so therefore to get good results, you need to enable both the hardware input conversion for textures and the output gamma conversion. There is no such conversion for vertex colours, so if they are already in linear sRGB (which they are coming from glTF 2), you just need the framebuffer flag to get them to show up right. So, option 2 will fix your vertex colours, and option 1 will fix your GUI textures, apply them both.
Note that panda3d-gltf already applies the sRGB decoding format to any applied textures, and panda3d-simplepbr already applies the framebuffer conversion. Only textures loaded programmatically or via some other pipeline will require the sRGB attributes to be set. So the only other thing to do is to enable framebuffer-srgb true.
The custom image filter just double-checks that the hardware framebuffer gamma curve conversion is enabled and if not, adds the conversion to the output filter shader. It is not normally necessary, except if you have buggy drivers or if you want to be able to toggle it without reopening the window, or something like that.
We probably need some more explanation of this in the manual, a dedicated page on linearized rendering. There is some information in this blog post:
Or these external resources:
In a future version (probably 2.0), Panda3D will use linearized rendering by default.
I will find the time to add more explanation to the documentation.
The link I posted is a specific link to the build output of a specific commit that I happened to have triggered the buildbot for manually. Since I’m not going to manually maintain links to specific commits on the download page, I think that we would need a page in WordPress that is able to show a list of the commits on each branch and associated downloads, in order to be generally useful.
This didn’t fix my GUI looking too bright. It fixed the textures, but not frames which I control their colors with setColorScale() to implement GUI themes in my programs. Is there a workaround for setColorScale()?
Interesting. Yes, if you specify colour values in code that affect the luminance of a texture, then the gamma will be off if you previously had gamma-encoded colour values.
You can linearize sRGB colours (so also colour scales) using decode_sRGB_float:
r = decode_sRGB_float(r)
g = decode_sRGB_float(g)
b = decode_sRGB_float(b)
I recommend making a utility function to convert an HTML colour into a Panda float vector that uses this function. Panda 1.11 is planned to have a utility class for this purpose.
I realised there was still a PHP script lying around to interface with the buildbot builds from the previous version of our website, so I did a minimum-effort attempt to bring it back into working order:
I mean, I don’t think that a full app is really called for: Blender already has a shader editor. All that’s required is an exporter that handles Blender’s node-based shaders.
Now, I didn’t watch the whole video: do they address the issue of changes in Blender’s API breaking such apps…?
Do we actually need to make a dedicated app or plug-in, or just a way to export Blender’s own shader nodes as GLSL or something like that? In a previous version of Blender, I know that the latter used to be possible.
It might also be possible to write a glTF extension to be able to represent Blender’s shader graph or an exported version thereof, and convince the Blender glTF exporter developers to accept a pull request to support it.
Depends on what you mean by “full app”. A “Blender app” allowing to export shaders would be basically lines of code mostly disabling other Blender windows and features, rather than adding anything new.
There’s basically two advantages:
It will not be Blender and be separate from Blender. So you can maintain it and update it when you please.
People who don’t use Blender and find it confusing will find it much easier to use a heavily stripped down Blender app that only does shader node editing.
I don’t think that this is accurate: I would think that a “Blender app” would still rely on Blender, and thus still be prone to changes in Blender affecting maintenance of the app.
I mean, at the least if it disables Blender windows, then it’s interfacing with Blender–and thus likely relying on Blender’s API. And if it’s exporting shader-nodes, then it’s likewise presumably interfacing with Blender’s internal structures, via said API.
That much is fair.
Conversely, however, I’m not sure that it wouldn’t be more common for users to want to use Blender as a full scene-/game-model- editor, including but not limited to its shader support. In whih case a stripped-down version of Blender might be less useful than simply having an exporter.
No it won’t, if you are a user.
It will reply on Blender, if you are the developer. However, in this case you, as the developer, do not need to worry about keeping the app up-to-date with the latest Blender API version, since as the video explains, you can distribute the app as a standalone exe not requiring a Blender install, so you can update it to a newer Blender API when you actually see the need for it, rather than just to make it usable with the new version of Blender which the users are assumed to upgrade to.
There’s enough data online which shows a lot of people struggle with Blender’s UI and choose another program.
However having both is not hard. A Blender app will go the extra effort to strip everything from Blender not needing shader editing, but you can also just distribute it as a script which does not have all that app stripping part.
It was, I think, the developer that I was thinking of.
Okay, that’s a fair point.
Conversely, however, doing so means that one misses out on beneficial improvements provided by updates to Blender, unless one takes on the question of keeping up with any changes to the Blender API incurred in such updates.
Is this still true with the newer versions of Blender? What I’ve been hearing is that those made some significant changes to the UI, making it more user-friendly, if I recall correctly.
In any case, Blender has generally been the recommended “scene editor” for Panda for some time now.
I’m not convinced of that: you end up with essentially two forks of the project to maintain. Much easier to maintain just one, I would think.
