LW 2018 Text Artifacts

[wilcoman]

I have a dilemna with trying to fix Text artifacts in modeler and layout.
I've created a text with the Text Layers function adding a slight bevel and extrusion.
in Modeler, the text shows with the triangle artifacts, which is a distraction more than anything. See Image
In Layout the text object renders with missing faces. I've flipped the front face and it still happens.
I even tried to make the face double sided, but it still renders missing front face.




Any ideas on how to resolve these two issues?

[prometheus]

I have a dilemna with trying to fix Text artifacts in modeler and layout.
I've created a text with the Text Layers function adding a slight bevel and extrusion.
in Modeler, the text shows with the triangle artifacts, which is a distraction more than anything. See Image
In Layout the text object renders with missing faces. I've flipped the front face and it still happens.
I even tried to make the face double sided, but it still renders missing front face.




Any ideas on how to resolve these two issues?

For anyone to do a proper checkup, please provide the object file/scenefile, or at least the text settings in a screenshot with font and other settings...You will get a much faster reply if doing so.
What font is it?

And the bevel extrusion in the textlayer doesn´t always create a full enclosed mesh on the text object, it could be missing faces, depends on bevel type, corner round may be safer to use..but depends on bevel inset when the settings aren´t locked/clipped ..when it is overriden, it can´t produce proper faces.

[Shloime]

Simple answers:

In Modeler it is just a OpenGL issue with concave polygons with a lot of points, so just a display error.
If you just manually subdivide your front polygons, you can control this effect.

The render error in Layout is because of overlapping corners because of your bevel. Look at the letter "t" at the end of your word (and every other letter, but "t" shows it best).
In the upper right corner of the letter you can clearly see overlapping geometry, which is causing render errors. Look at my picture.


You need to find those overlapping corners and weld them manually or find some better text tool.

[prometheus]

Simple answers:

In Modeler it is just a OpenGL issue with concave polygons with a lot of points, so just a display error.
If you just manually subdivide your front polygons, you can control this effect.

The render error in Layout is because of overlapping corners because of your bevel. Look at the letter "t" at the end of your word (and every other letter, but "t" shows it best).
In the upper right corner of the letter you can clearly see overlapping geometry, which is causing render errors. Look at my picture.


You need to find those overlapping corners and weld them manually or find some better text tool.

No..I don´t think it´s just an opengl display Error , there are in fact no polygonfaces in the missing polys here, this texture layer with extrusion, and when the bevel or extrusion is overlapping, it isn´t creating faces in those circumstances.
Ivé bee checking this with extruded beveled text, and dissecting it by removing polys and trying to select the face polys that in such case should be only a render issue, but the polyfaces are simply not there.

Edit..well it might be anyway..in this case, depends on how it was extruded..sorry.

[Sensei]

Bevel tool work this way:
make duplicate of selected polygon, offset its points, move them to implement inset feature.
so overlaps may happen, if user is not careful.
It is not designed to be boolean tool!

To not have overlaps any such modeling tool would have to be designed to work this way internally:
generate negative version of the mesh,
boolean subtract current one mesh and negative version,
delete negative version of the mesh.

wilcoman,
I created TrueArt's True Type Text plug-in which works directly inside of Layout:
http://truetypetext.trueart.eu
However, you can export mesh generated by my plug-in to Modeler, and modify it, if you want to.

[prometheus]

There is a bevel extrude function in the text layer tool, if not careful..it will fail to create faces when the bevel overlap depending on bevel amount, Initially I thought that was the issue here, but then I noticed that there at least was a diagonal face split in his text, thus the other part of the face is merely an opengl issue,or render issue and not a missing face issue, and as shloime said, it would need a proper welding, the faces should be there in that case.

[wilcoman]

For anyone to do a proper checkup, please provide the object file/scenefile, or at least the text settings in a screenshot with font and other settings...You will get a much faster reply if doing so.
What font is it?

And the bevel extrusion in the textlayer doesn´t always create a full enclosed mesh on the text object, it could be missing faces, depends on bevel type, corner round may be safer to use..but depends on bevel inset when the settings aren´t locked/clipped ..when it is overriden, it can´t produce proper faces.

Thanks guys. I'll try to get the information on the font used, and scene files, etc.Happy.lwo

[prometheus]

Thanks guys. I'll try to get the information on the font used, and scene files, etc.Happy.lwo

Checking it, as far as I can see, you do not have overlapping bevels, neither any missing polys due to the text layer bevel, it is non planar faces, and opengl errors, you need to connect them, as I did in these images, and in the object file, the object file is for you to select the faces that still is none planar after I connected two points in the top parts, and two points in bottom parts, I did this on both the front and back side till the diagonal errors where gone, to fix this none planar blackness you see on the faces , select them and triple them with shift-T and directly after that you click shift-z to merge polygons ..that should fix it.

Not very nice if it´s a lot of text though.

connect these selected points "l" then the same on the other back side of the text mesh...






This fixes the errors of geometry outside of the text, but still none planar...






Fixing that none planar by selecting that dark part of the surface that indicates it´s none planar, then triple with shift-t, then merge polys with shift-z...









There´s also a number of 666 vertices in the mesh, must mean something

[wilcoman]

Thanks Prometheus for taking the time to investigate this issue for me. Since this text, and others, was part of LW text conversion algorithm, I'm guessing it's native in the translation of some fonts.
I have other fonts that do not present this issue at all. Thats a whole lot of steps to fix an issue like this, so I'll probably move to a different font in the future and see if it resolves.
As far as the 666 issue, I can only answer John 3:16
Take care and thanks again. You're awesome.

[Rayek]

This is strange: when I open the file in Accutrans, the artifacts no longer appear, but checking the mesh for holes reveal problems in the H and Y ( front polygons are missing).

When I save as an obj file, and check the mesh in Blender: no polygon artifacts, but the H and Y's front polygons are missing. Otherwise all lettering looks fine, just as in Accutrans.

In Blender I filled the front and back faces of the H and Y, and then cleaned out doubles (there were a few of them). Saved as OBJ, and loaded in Accutrans. No issues. But when I load that OBJ file in Modeler, the same H and N polygons still spazz out. Other issues were resolved, though.

Next I load the Blender cleaned OBJ file in Accutrans, and export as an LWO. Result: issues are gone in Modeler.

How weird, I think: the OBJ file in Modeler retains those poly issues, while the Accutrans saved LWO version does not?

So next I open the Happy.lwo directly in Accutrans, and, without any changes, save it as a new LWO file. Open it in Modeler.

Result: problems fixed. The front and back faces of the H and Y must be filled, and that's it.

As far as I can tell, there might be a bug at work here in Modeler? Or Accutrans fixes the LWO data somehow. But why is Modeler having these polygon issues when both Accutrans and Blender have no problems with the same OBJ data? Quite strange. ( The Windows 10 3d object viewer also demonstrated the same issues as Modeler, btw)

Anyway, simple solution: 1) open in Accutrans; 2) re-save as LWO, and load up in Modeler; 3) fill the holes in the H, W, and Y.
Preferably also remove the double vertices.

Goes to show once again how useful Accutrans a tool is in one's toolbox.

PS Saving the fixed lettering from Blender as DAE file does load it up correctly in Modeler as well.
PPS performing the same bevel with the same font causes no issues in Blender.

[prometheus]

This is strange: when I open the file in Accutrans, the artifacts no longer appear, but checking the mesh for holes reveal problems in the H and Y ( front polygons are missing).

When I save as an obj file, and check the mesh in Blender: no polygon artifacts, but the H and Y's front polygons are missing. Otherwise all lettering looks fine, just as in Accutrans.

In Blender I filled the front and back faces of the H and Y, and then cleaned out doubles (there were a few of them). Saved as OBJ, and loaded in Accutrans. No issues. But when I load that OBJ file in Modeler, the same H and N polygons still spazz out. Other issues were resolved, though.

Next I load the Blender cleaned OBJ file in Accutrans, and export as an LWO. Result: issues are gone in Modeler.

How weird, I think: the OBJ file in Modeler retains those poly issues, while the Accutrans saved LWO version does not?

So next I open the Happy.lwo directly in Accutrans, and, without any changes, save it as a new LWO file. Open it in Modeler.

Result: problems fixed. The front and back faces of the H and Y must be filled, and that's it.

As far as I can tell, there might be a bug at work here in Modeler? Or Accutrans fixes the LWO data somehow. But why is Modeler having these polygon issues when both Accutrans and Blender have no problems with the same OBJ data? Quite strange. ( The Windows 10 3d object viewer also demonstrated the same issues as Modeler, btw)

Anyway, simple solution: 1) open in Accutrans; 2) re-save as LWO, and load up in Modeler; 3) fill the holes in the H, W, and Y.
Preferably also remove the double vertices.

Goes to show once again how useful Accutrans a tool is in one's toolbox.

PS Saving the fixed lettering from Blender as DAE file does load it up correctly in Modeler as well.
PPS performing the same bevel with the same font causes no issues in Blender.

The original lwo text mesh file isn´t missing any faces or lack of filling polygons(well front polygons sort of)
when I go through the text mesh on back and front side, the faces are all there but flipped in some cases and non planar.

For not to much text..my route I described above is quite simple, without too much work and no need for leaving modeler, however ..if there is a lot of text to deal with, using some other software to fix it as you mentioned can be a way to go.
I simply just connect the points on the bottom horisontal footer shape and header shape of the letters as seen in the images I posted, then w for statistics, and select all the non planar faces, shift-t to triple, shift-z to merge faces again...takes maybe a minute, done.

By the way, have you ever gotten these kind of artifacts when working with the text tools in blender?

[jwiede]

Just my $0.02, but anyone who wants to convert fonts into geometry for further operations should either use TrueArt's Font plugin, or generate the initial glyph->geo in some other 3D pkg. Save yourselves the time and effort of fighting to generate "decent" glyph geometry in LW -- if that doesn't work great right off the bat, it's NOT worth the hassle.

LW's native glyph->geo capabilities are typographically very limited, often generate junk geometry, holes, odd normal orientations, and so forth. Existing problems then get further magnified by subsequent LW geo operations. You're much better off to start with "clean" glyph geometry from another pkg, and then work from that in LW if needed (though probably makes more sense to do all geo work needed in other pkg, if you're already doing text->geo in that pkg).

Converting font glyphs to geometry and providing for MoGraph-type manipulations of that geometry are among native LW's weakest feature areas.

[Rayek]

The original lwo text mesh file isn´t missing any faces or lack of filling polygons(well front polygons sort of)
when I go through the text mesh on back and front side, the faces are all there but flipped in some cases and non planar.

For not to much text..my route I described above is quite simple, without too much work and no need for leaving modeler, however ..if there is a lot of text to deal with, using some other software to fix it as you mentioned can be a way to go.
I simply just connect the points on the bottom horisontal footer shape and header shape of the letters as seen in the images I posted, then w for statistics, and select all the non planar faces, shift-t to triple, shift-z to merge faces again...takes maybe a minute, done.

By the way, have you ever gotten these kind of artifacts when working with the text tools in blender?

Have you tried opening the original LWO file in Accutrans? It reports holes. There are no other issues compared to Modeler. That is rather odd in my opinion.

I wonder why Accutrans and Blender display this mesh so very different compared to Modeler.

As for your question: No, nothing like that. The quality of the bevel depends on the type family, of course. Some fonts are not that suitable, and require a larger offset to accommodate the bevel geometry. You are probably aware that the latest versions added super-simplified custom profile support with a curve graph? The updated bevel function seems to work better than before, since it uses the updated bevel code now (I believe).

Anyway, the font example in this thread posed no issues when adding a bevel modifier.

[prometheus]

Have you tried opening the original LWO file in Accutrans? It reports holes. There are no other issues compared to Modeler. That is rather odd in my opinion.

I wonder why Accutrans and Blender display this mesh so very different compared to Modeler.

As for your question: No, nothing like that. The quality of the bevel depends on the type family, of course. Some fonts are not that suitable, and require a larger offset to accommodate the bevel geometry. You are probably aware that the latest versions added super-simplified custom profile support with a curve graph? The updated bevel function seems to work better than before, since it uses the updated bevel code now (I believe).

Anyway, the font example in this thread posed no issues when adding a bevel modifier.

No..I haven´t, I don´t have accutrans.

Where do it report holes, do you mean the full face of a letter, or just not welded points?

As for checking it in modeler, the faces are there, just flipped wrong..no matter what side I choose and select the front or back facing polys of any letter, it gets selected..so the faces are there at least, so I am not sure of what holes you refer to?
I have no issues of just adjusting the errors, the errors are on the front and back faces of the text, they are all over 4 vertices, just need to close them properly to ensure a true flatten of the faces I think, it´s easy to do by selecting those points I refered to and connect with "l" then select all the resulting non planar faces in the statistics tab and triple then merge polygons, that´s it.

Exactly why this flattness or opengl issue still is there after all these years for lightwave modeler, I honestly do not know.

[prometheus]

Just my $0.02, but anyone who wants to convert fonts into geometry for further operations should either use TrueArt's Font plugin, or generate the initial glyph->geo in some other 3D pkg. Save yourselves the time and effort of fighting to generate "decent" glyph geometry in LW -- if that doesn't work great right off the bat, it's NOT worth the hassle.

LW's native glyph->geo capabilities are typographically very limited, often generate junk geometry, holes, odd normal orientations, and so forth. Existing problems then get further magnified by subsequent LW geo operations. You're much better off to start with "clean" glyph geometry from another pkg, and then work from that in LW if needed (though probably makes more sense to do all geo work needed in other pkg, if you're already doing text->geo in that pkg).

Converting font glyphs to geometry and providing for MoGraph-type manipulations of that geometry are among native LW's weakest feature areas.

I may agree, if the fonts used not created nicely, discard that in a memory list for Lightwave and use some other font, if necessary to use that font, use something free like blender, unless you can afford to pay for senseis plugin to cover up such a bad text tool which should be fixed natively.

What lightwave does though, is to get your brain going to try and solve it by disecting the faces, polys and points etc..this is only for those who have nothing better to do and a lot of time over when doing it

Text in blender is however initially curves, and they are tripled and thus yielding more geometry than lightwaves text generation tools, thus if you do not want tripling(though the tripling is sort of what makes it work in blender)
You have to first convert to mesh the decimate it planar.




if you copy and paste that in to lightwave with od paste, it will still be tripled though, so if you don´t want that, apply the decimate modifer first then od copy and paste, but then yo will face flipped faces, which you have to flip.

Image...blender text to lightwave, converted to mesh, decimate to make planar, applied the modifier properly, od copy and paste to lightwave, then flipped some front faces..so you still need to adress polys in Lightwave no matter what..even after creating it in another software, unless you keep it triple with extra geometry ..then again, you could just as easy triple faces in lightwave, what you don´t have to do is to connect the faces which is already done in blender, between the points I highlighted in the image, in lightwave that isn´t automaticly created.