VL.Stride.Text3d

wip
#1

image

Set of nodes to create (and render) extruded 3d text in VL.Stride.
It’s heavily inspired by @vux beta/dx11 (3d)Text nodes.

The nodes make use of Extruder.cs, ExtrudingSink.cs and OutlineRenderer.cs that come with dx11-vvvv. I only made some minor changes. His code is licensed under BSD 3, refer to DX11-vvvv-License.md for details.

The library itself is released under MIT license.

To use latest version, install via nuget

nuget install VL.Stride.Text3d

Known issues

  • Help patch is rather barebones.

  • 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.

14 Likes
#2

Thanks, and get well soon!

2 Likes
#3

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.

#4

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?

#5

Thanks, the rendering works again!

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.

#6

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.

Faulting application name: vvvv.exe, version: 2022.5.0.0, time stamp: 0x6387d353
Faulting module name: coreclr.dll, version: 6.0.1322.58009, time stamp: 0x6387cbf1
Exception code: 0xc0000005
Fault offset: 0x00000000001d2191
Faulting process ID: 0x2984
Faulting application start time: 0x01d942ea1b0b34f7
Faulting application path: D:\_vvvv\vvvv_gamma_2022.5.0-0582-g69e6cbc026\vvvv.exe
Faulting module path: C:\Program Files\dotnet\shared\Microsoft.NETCore.App\6.0.13\coreclr.dll
Report ID: e4b911ef-940d-4893-b70d-950de3626115
Faulting package full name: 
Faulting package-relative application ID:

So for now if you just want to play arround you can start vvvv with said argument.

Maybe @Elias has some time and can look into it.

#7

Hm, not sure it’ll help you much, but that’s what VS reports:
image

#8

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.

#9

Any idea why it is only happening when the package is pre-compiled?

#10

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.

#11

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.