Overlighted model

[avilkinnick]

Why is my .vsgt model (and .osgt that I converted it from)

is so overlightened compared to .gltf model that I got by converting .osgt to .obj and then by exporting it in Blender in .gltf

And how I can make so that .vsgt model show the same result

[robertosfield]

I suspect this is a gamma correction issue in older VSG versions being affected by changes to recent versions that default to sRGB. Was your .vsgt model created before VulkanSceneGraph v.1.1.10?

The topic of Gamma correction and sRGB textures/framebuffers is covered in the thread:

#1379

[AnyOldName3]

AnyOldName3/vsgExamples@a5331a8#diff-28321ebb550c3b8760e1cd86bdf0ce617c7d577d9f7560e658f08f5da947e6d6 shows some of the things you might need to do to adapt to make a non-gamma-correct .vsgt file work in modern gamma-correct VSG.

That said, most of the time, I'd recommend storing models as glTF if possible. When something in the VSG changes, we can update the glTF loader to do the right thing, but with a .vsgt file, we're not interpreting data according to a specification and mapping it onto how the VSG represents things internally, we're just loading an internal representation, and there's nothing to tell us if something is the way it is for a good reason so we should leave it alone, or because it's using an old convention and would benefit from conversion.

[robertosfield]

osgconv? Do you mean the OpenSceneGraph's osgconv? Or do you meant vsgconv from vsgXchange which is VulkanSceneGraph's equivalent to osgconv?

As a general comment, I would recommend avoiding using OSG and osg2vsg for art path, so unless it's originally .osgb or .osgt use vsgXchange::assimp instead.

osg2vsg is also now very old compared to the rest of the VSG and needs a complete rewrite to use modern VSG features like ShaderSet/GraphicsPipelineConfigurator.

[avilkinnick]

I just have original models only in .osgt and .max formats and at best I want just to convert them to .gltf without loss of any local transformations. .vsgt was only mentioned there because I thought that it would be easier now to stay with it, but if there is an easy way to convert to .gltf I will be very glad to know it

[robertosfield]

Convert from what to what for what reasons?

[AnyOldName3]

.obj is a bad format to use as an intermediate stage as it inherently doesn't support things like local transformations. You need to make sure you don't use a step that throws away data you want to keep. If you've got access to 3DS Max, then that has native support for loading .max files (obviously) and native support for exporting .glTF (although you'll find that glTF only supports PBR materials, and if you've got old Max files, they probably predate PBR and use Phong materials, so you might be better off with something like FBX that has better legacy pipeline support). For .osgt, things might be tricky as, just like .vsgt, they can contain arbitrary data with application-specific meaning, and if your files do, then you might need to build an application-specific converter.

[avilkinnick]

@robertosfield from .osgt to .gltf for easier editing in 3d editors and consistency with new models that will be made in blender and exported in .gltf

[robertosfield]

How/why does .osgt fit in here?

…

On Tue, 1 Apr 2025, 08:10 avilkinnick, ***@***.***> wrote: @robertosfield <https://github.com/robertosfield> from .osgt to .gltf for easier editing in 3d editors and consistency with new models that will be made in blender and exported in .gltf — Reply to this email directly, view it on GitHub <#1429 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKEGUGFPFGPGDYL5IZSR532XI3WRAVCNFSM6AAAAABZ7RBH6SVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTENRYGQ4DIMA> . You are receiving this because you were mentioned.Message ID: ***@***.*** com>

[avilkinnick]

Most of currently existings models that we have are in .osgt format, they were converted long ago and for some of them we have original models in .max format. Now we want to use .gltf, but we cannot convert neither .max nor .osgt to .gltf without loss of local transformations that we actually need

[robertosfield]

With the .osgt files osg2vsg will currently convert to VSG but will implement it's own set of shaders, not any of the new vsg::ShaderSet that are built-in and have support for lighting and shadows. Longer term I'd like to see a rewrite of osg2vsg which addresses this.

The .osgt to .obj to Blender to GLTF route sounds a bit painful, but would at least allow vsgXchange::assimp to build the scene graph with modern vsg::ShaderSets and have full support for lighting and shadows. But... .obj is such a feature poor format you are loosing too much info.

I am not familiar with osgReciplies but I believe it might have a GLTF loader, if it also has a GLTF writer then perhaps this would be a solution.

Another route would be to bypass osg2vsg and write a custom OSG converter that loads .osgt and converts to .vsgb/.vsgt, using ShaderSet/GraphicsPipelineConfigurator as vsgXchange::assimp does. Or just rewrite osg2vsg itself.

One thing to be aware of though is that the OSG isn't at all sRGB aware, so just assumed everything as linear RGB, but in fact the source images were almost always sRGB and there was an implicit sRGB conversion being done on the framebuffer. By fluke this "kinda" worked, but once you put the data into a scene graph that actually handles sRGB source data and sRGB frame buffers correctly you see issues.

I go into this in depth in this topic in the thread #1379.

The OSG will be loading sRGB images as RGB so setting the format to RGB, whereas it really should be setting them to sRGB, the thread discusses this, so it might be enough to just go through the the image data and change the format from a RGB/RGBA to a sRGB equivalent.