The texture coordinates are just dummies. edit: added planar UVs
Not sure about:
Position
Fonsize / size correlation
When creating more than one model at once, something seems to go wrong with the normals.
This can be worked arround by “reconnecting” the Entity (see the explanation patch) or creating the models sequentially. I guess this is somehow related to the Generate[PrimitiveProceduralModelBase] method, since it doesn’t happen at all when creating a mesh from a vertexbuffer (as done in the now marked as obsolete Text3dMesh (Async) ).edit: seems to be fixed now
I am not really happy how FontAndParagraph and recreating the model on changes is set up now. But my brain is somewhat foggy due to covid, so at least for now it is what is.
Just checked out the help patches in several 22.5 previews, the 3D text is not displayed in the renderer. Additionally vvvv crashes when trying to select another font.
Just pushed an update. From now on use the following when installing the nuget:
For 5.0
nuget install VL.Stride.Text3d
For 2021.4
nuget install VL.Stride.Text3d -version 0.4.0
@Elias 5.0 no longer comes with SharpDX.Mathematics, for now I added it as dependency to Text3d so it also gets installed. Is this the way to go or can/should I somehow switch to Silk.NET.Maths which seems to be what vvvv is using now?
Still the help patch “TextStyles” crashes when selecting another font (is it because the font of yours is not pre-installed?), also both help patches make vvvv crash when they are closed.
It didn’t crash for me during testing and it just occured to me that I used the --disable-package-compiler argument during development.
As soon as I start vvvv “normally” I also get the crashes.
Unfortunately the error messages in event viewer are a bit sparse:
Application: vvvv.exe
CoreCLR Version: 6.0.1322.58009
.NET Version: 6.0.13
Description: The process was terminated due to an internal error in the .NET Runtime at IP 00007FFD8B332191 (00007FFD8B160000) with exit code c0000005.
I see that you make use of the “cache region auto dispose feature” in FontAndParagraph. Maybe that is not a good idea in this case. It could be that it’s mandatory to dispose TextLayout before TextFormat.
Not sure. But access violations are tricky in that regard - it depends on the memory allocated / how the heap looks like. And pre compiled it definitely looks different than when not.
That seems to have been the cause. Disabled “auto dispose” for TextFormat for now and the crash is gone. Guess I’ll have to revisit the issue in the future and check if I can implement a “proper” way for disposing.
@chk latest version (1.0.2) should no longer crash.