- This topic has 16 replies, 3 voices, and was last updated 1 year, 10 months ago by
.
-
Hello everyone,
I think I am reviving an old thread, but I have a model with custom split normals, but these are ignored in verge3D after the gltf-export.
The only “solution” I found was: use a data tranfer modifier. I don’t really know what to do exactly. I added the modifier and then what?
I tried the Face Corner Data – Custom Normals setting in the modifier and used a copy of the same model as source. No change.
What is the correct procedure here? Help is very much appreciated!
I just fixed it. All I needed to do was apply smooth-shading once more and tick the auto smooth checkbox on the export-mesh. Now everything works.
BUT: Why this “complicated” procedure? And what do we do when we want to animate these objects. Parent the source-mesh with custom normals to the export-mesh to not break the modifier? Thats not very practical…
Is there a way to make custom normals work natively on export? Those are very common in game engines so it would be nice if you could use them “natively” in verge3D.
and tick the auto smooth checkbox on the export-mesh
The
Wheighted normalmodifier won’t create custom split normals data if this option is disabled. If you disable this option after adding custom split normals they won’t be applied in Blender and won’t be exported to glTF.
And what do we do when we want to animate these objects
Just animate them. Nothing will happen with the custom split normals.
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.
The Wheighted normal modifier won’t create custom split normals data if this option is disabled. If you disable this option after adding custom split normals they won’t be applied in Blender and won’t be exported to glTF.
Well you need to use the DataTransfer modifier, not the WeightedNormal. And yes as I said, I checked that box. But: I already had that. I had to uncheck it, enable smooth shading again (it already was) und then check that box again. Now it works.
Unfortunally, animation of modifiers not supported and seems no change for this in near future.
Animating values inside the modifiers will not work because they will be baked (well at least for now). So that is obvious!
What I meant was animating the object itself with the DataTransfer modifier on it. That is what I am doing. And I have to parent the source-mesh to the export-mesh, otherwise on export the modifier will not be baked correctly into the gltf-file.So my question remains: Will there be native custom split normals support in verge3d sometime in the future? And by that I mean: Custom normals work in blender (and other 3d apps) without any modifiers. In Blender you have your 3D-model, create or import the custom normals -> smooth shading -> activate auto smooth: Done.
For them to also work in verge you need to duplicate your model, delete the custom normals on this 3d-model and then re-apply them via the DataTransfer modifier from the other duplicate (used as source inside the modifier) that still has the custom normals.Custom normals are widely used in the gaming industry -so realtime applications like verge- so being able to use them without this duplicate-modifier-pipeline would be very useful!
:)They supported aleady from the day they was added to Blender. All custom normals will works fine in Verge3D – we have a lot of demos with split custom normals on some objects.
Yes they do work – but only with this duplicate-modifier workflow. If I have a model with custom split normals and just directly export to verge, they do not work. It least not in my tests.
To close this thread: Once I applied the DataTransfer modifier everything worked from this point forward.
It must have something to do with my obj-files. When iported, blender shows the correct shading with custom normals. In verge3D they do not work… Only after my complicated workflow. Very strange. Other objects with custom normals work directly as intended. Thanks to everyone for their help!
- You must be logged in to reply to this topic.