We use cookies to ensure that we give you the best experience on our website. If you continue to use this site we will assume that you are happy with it.

Ok, I Agree

materials: has this changed in 4.6?

Home › Forums › Graphics / Blender › materials: has this changed in 4.6?

Viewing 13 posts - 1 through 13 (of 13 total)
  • Author
    Posts
  • 2024-06-27 at 1:36 pm #75623
    kvdml
    Customer

    The last project was in v4.2: I made a huge configurator (800 objects, 40 materials, 300 billion configurations).
    In v4.2 I could append scenes and assign PBR materials to them with no trouble.

    The company I worked for, no longer does that production, so I’ll go freelance. I’m brushing up my Verge-skills, and in 4.6 trial: I can no longer assign materials with maps without making them glTF compatible.

    If I assign a PBR material to an object, the object turns black. If I assign a copy of the PBR material, that has been checked as ‘glTF 2.0 compatible: the material is shown on the object.

    The only case on which the standard material is applied, is when the object is loaded with a pbr

    I checked my files from last years project, and none of the materials were set as glTF-compatible

    I usually code directly in the visual_logic.js, but for small tests, I quickly set up some puzzles, so, I added a screenshot

    • This topic was modified 4 days, 5 hours ago by kvdml.
    Attachments:
    You must be logged in to view attached files.
    2024-06-27 at 2:02 pm #75626
    kvdml
    Customer

    found the error by logging the xhtml-request:
    Fetch failed loading: GET “http://localhost:8668/applications/Shapeshift_tester/cobblestone_floor_04_diff_1k.ktx2”.
    Fetch failed loading: GET “http://localhost:8668/applications/Shapeshift_tester/basis_transcoder.wasm
    Both files are there though

    2024-06-27 at 2:17 pm #75627
    kvdml
    Customer

    fixed the errors, no change

    2024-06-27 at 4:26 pm #75630
    Alexander Kovelenov
    Staff

    Hi,
    In general glTF-compatible option should not be used if you have no intention to export to fully-glTF-compatible assets.

    Perhaps the issue is with UV maps or tangents missing due to optimizations. In the first case, verify that the source and target meshes have the same amount of UV maps (preferably with the same order and names). In the second – try to disable “Optimize Mesh Attributes” in export settings.

    Soft8Soft Tech Chief
    X | FB | LinkedIn

    2024-06-27 at 8:03 pm #75634
    kvdml
    Customer

    thanks, disabling the ‘optimize mesh attr.’ worked for the cubes in the masterscene. Not for the appended geo that worked in a v3d 4.2 project. I’ll have a look at it this weekend.

    2024-06-27 at 8:19 pm #75635
    kvdml
    Customer

    just did a quick test: the imported object does not get the pbr material assigned when it’s a standard glb. A v3d glb version works.
    This was not a problem in version 4.2
    Also, the Verge .glb is almost double the size in kb 1.2 mb for the Verge version, 680 kb for the standard glb.
    After XZ compression, this goes to 385kb vs 184kb

    2024-06-27 at 9:31 pm #75636
    kdv
    Participant

    Did you test the DRACO geometry compression? The size will be even smaller, loading time much faster. But they in S8S removed DRACO support from GLTFLoader in 4.7.0 :negative: Did it make 4.7.0 faster and better? Absolutely not.

    Puzzles and JS coding. Fast and expensive.

    If you don’t see the meaning in something it primarily means that you just don’t see it but not the absence of the meaning at all.

    2024-06-29 at 3:05 pm #75679
    Alexander Kovelenov
    Staff

    We usually don’t recommend mixing Verge3D-based assets and standard glTF into the same app, since such configurations cannot be properly tested. Also, the excessive size might be due to the fact that most Verge3D assets include an HDR map which cannot be compressed efficiently (you might remove it though).

    Regarding DRACO, IMHO this format can’t be considered as a silver bullet for all possible usage cases. See comparison we did some time ago.

    Soft8Soft Tech Chief
    X | FB | LinkedIn

    2024-06-29 at 5:51 pm #75681
    kvdml
    Customer

    I removed the world shader node of my object in Blender, v3d gltf size dropped to 946kb ‘(from 1.2Mb). xz-compression dropped it to 364 kb, which is not a huge difference with the xz-compression of the object with world-shader node (385 kb).
    It would be nice if in future versions we could decide ourselves what mesh attrs could be optimized: the optimized mesh attr. version is comparable with a plain glb in filesize (696kb uncompressed, 219 kb with xz compression). Too bad it’s not compatible with v3d pbr shaders with maps.
    Thanks for the info though, Alexander.

    2024-06-29 at 7:38 pm #75687
    kdv
    Participant
    Alexander Kovelenov wrote:

    See comparison we did some time ago

    I did already see that comparison and it’s not correct ))) That’s a private case. Do you really believe that LZMA is 10 times more effective? :scratch: Instead of 10 non-instanced copies take 10 different meshes or 10 instanced copies. Besides, DRACO-compressed geometry can be easily packed with LZMA resulting in even smaller file size.

    Test scene – https://v3d.net/cr5
    Verge3D-exported .bin file – 14.7 mb, LZMA-compressed – 4.6 mb (100%)
    DRACO-compressed .bin file – 2.18 mb, LZMA-compressed – 1.76 mb (38%)

    I’m not saying that you should add DRACO geometry compression because you won’t do it ))) I’m asking why did you remove DRACO extention recognition? It was working fine but you broke it :negative:

    Puzzles and JS coding. Fast and expensive.

    If you don’t see the meaning in something it primarily means that you just don’t see it but not the absence of the meaning at all.

    2024-06-30 at 12:09 pm #75689
    Alexander Kovelenov
    Staff
    kvdml wrote:

    It would be nice if in future versions we could decide ourselves what mesh attrs could be optimized: the optimized mesh attr. version is comparable with a plain glb in filesize (696kb uncompressed, 219 kb with xz compression). Too bad it’s not compatible with v3d pbr shaders with maps.

    This optimization is basically removal of Tangent attributes (needed for normal mapping) which require 4 additional float values per vertex. Perhaps we should consider making per-mesh setting instead of the global one. For now I might suggest making two scenes: one with normal mapped shaders and models which require tangents. Another which don’t require them.

    Soft8Soft Tech Chief
    X | FB | LinkedIn

    2024-06-30 at 12:20 pm #75690
    Alexander Kovelenov
    Staff
    kdv wrote:

    I’m not saying that you should add DRACO geometry compression because you won’t do it ))) I’m asking why did you remove DRACO extention recognition? It was working fine but you broke it

    I can surely understand your frustration on this, however we have quite limited resources and basically have no other options but to remove the features what we have no intention (or time) to support. Basically all the stuff inherited from Three.js which is not in direct use for most of our users will be removed sooner or later. This is how we see the future of Verge3D.

    Soft8Soft Tech Chief
    X | FB | LinkedIn

    2024-06-30 at 11:36 pm #75692
    kdv
    Participant
    Alexander Kovelenov wrote:

    Perhaps we should consider making per-mesh setting instead of the global one.

    Or you can add a simple puzzle to compute tangents when needed. Or you can check in “assignMaterial” function if normal map is used and compute tangents.

    mesh.geometry.computeTangents();

    Just do not remove this feature although it’s not used by 99% of Verge users! B-)

    Puzzles and JS coding. Fast and expensive.

    If you don’t see the meaning in something it primarily means that you just don’t see it but not the absence of the meaning at all.

  • Author
    Posts
Viewing 13 posts - 1 through 13 (of 13 total)
  • You must be logged in to reply to this topic.