R Soul on 13/6/2019 at 21:54
Recently I've been working on updating (
https://www.ttlg.com/forums/showthread.php?t=136431) Telliamed's .e file addon for Blender so it'll work in version 2.8. I've been making progress. One of the snags I hit was that sometimes I'd get narrow slits in an object:
Inline Image:
http://catmanofiowa.com/RSoul/img/model_gaps.jpgThis is a distorted bed and the basic cuboid was split 3x5 to allow the surface to be uneven. After trying various things the only thing that worked was to use BSP from the command prompt (until then I'd been using 3ds->bin) with the parameter "-ep" followed by some number.
Using that, the result looks fine:
Inline Image:
http://catmanofiowa.com/RSoul/img/model_no_gaps.jpgWhat puzzles me is that it doesn't seem to matter what number follows the -ep parameter. e.g. -ep12 seems to produce the same result as -ep0.000005. I can also use -ep0, also with the same result.
When the value goes below 0.4 I get this sort of output:
Code:
Non convex -0.020672
yo, only -1 points left
Non convex -0.020672
yo, only -1 points left
Also a slight reduction in reported poly count.
My intention is to use Blender to send the .e file to BSP*, so it would be nice to understand that -ep parameter. From what I've read coplanar refers to a set of points that are on the same plane. I presume the value is some kind of tolerance or threshold, but then I'd expect those two very different test values to produce visually different results.
I could have that value as a user option so that people don't get stuck if their model ends up with gaps, but it would be nice to know roughly what it does so I can at least set a reasonable default value. Any ideas?
*similar to the (
https://www.ttlg.com/forums/showthread.php?t=134384) Dark Exporter (which also uses 3ds2e, but that can only be done up to Blender 2.79)
john9818a on 14/6/2019 at 12:46
I know this comment is no help, but the first thing that popped into my mind was epsilon. I've seen that term somewhere before maybe in game rendering.
PinkDot on 14/6/2019 at 16:03
It may be doing a mesh optimization, like merging close to coplanar mesh triangles together. I think nowadays the best way is to leave any mesh optimization to a user in a 3d application and find a value of -ep that does not change the model's topology at all.
R Soul on 14/6/2019 at 20:14
You're both right, the e in that parameter stands for epsilon (p is for plane or planar).
Here is the list of parameters for BSP:
Code:
bsp: iname [oname] [options]
-c<1>,<2> : map material 1 to color 2, <1>=@ means map all mats
-w<1> : map material 1 to wire, <1>=@ means map all mats
-b<1> : map material 1 to dblsided, <1>=@ means map all mats
-v<1> : map material 1 virtual,<1>=@ means all mats
-i : make output includeable
-C : make output with compound ref header
-n<name> : define object name
-o[x(+|-)][y(+|-)][z(+|-)] : center object about its centroid
or bias any axis to its max (+) or min (-).
-s<#|<x|y|z><#>> : scale object
-r<x|y|z><#> : rotate object
-t<x|y|z><#> : translate object
-d<1>,<2> : debug, make every pgon a different color from 1 to <2>
<1> sets debug level, 0=by pgon,1=by node
2=mono,3=merged pgons,4=cluster,5=intersected
6=show hulls 7=no atomic, show inter
8=show poly slivers
9=show bad tmaps in u
10=show tiling tmaps in v
-l<1> : level of optimization 0-3, 0=least splits, 3=maximum speed
-L : no lighting. 0=no sorting
@<fname> : run response file fname
-f<fname> : fun materials file fname
-es<1> : shrink subobjs by 1 to make them fit, def 1
-ee<1> : set epsilon
-et<1> : set thickness
-ep<1> : set coplanar limit
-el<1> : set colinear limit
-ev<1> : set vert epsilon
-V : verbose mode, shows linkages
-M<1> : set smoothing group threshold, -.5 (120 deg) is default, cos(ang)
-N : No Sort. Do not sort
-a<ang> : sets axle 360 degree range limit, default 100.
A<1> : Bias against using atomics to split. Default 0.
-mo : mesh output
The first thing I tried was the optimization level, but that made no difference.
Here's the mesh before export:
(
http://catmanofiowa.com/RSoul/img/tris_before.jpg)
Here it is having been converted to bin and then back to 3ds:
(
http://catmanofiowa.com/RSoul/img/tris_def_opt.jpg)
You can see how two pairs of triangles have been needlessly merged, and some unnecessary splitting has occurred.
Here it is with optimization of 0, but still the other triangles are merged:
(
http://catmanofiowa.com/RSoul/img/tris_opt_0.jpg)
Optimization 0 and -ep12:
(
http://catmanofiowa.com/RSoul/img/tris_opt_0_ep_12.jpg)
I can't see a difference with other -ep values, so all I know is that the -ep switch prevents incorrect triangle merging, but the meaning of the number is still a mystery. 12 what? Why do 12, -5, 0 and 85 all produce the same results? I might implement a user option for this value and call it "Coplanar Optimization" so people can change it if they get troublesome output.
caffeinatedzombeh on 14/6/2019 at 21:48
I would assume it's in the same units as the object itself, so 0 is "everything must be perfectly aligned and no I don't care that you're using floats in a computer" and 1 is "a foot is near enough isn't it?"
I'd be quite surprised if you'd ever need to change it from the default which will be a number very close to 0 and you'd have to be making quite an odd object for it to care.
It'll be checking whether some vertex is coplanar with the poly next to it and if the normal distance from the plane is less than that value then it is.
0.001 is probably as big as you'd want to go? and 0.00001 more the normal sort of value?
Subdividing a flat plane for better lighting resolution is likely to annoy it. Make stuff less flat or merge the flat bits more yourself so it doesn't have a choice :)
R Soul on 15/6/2019 at 20:26
Thanks for your reply.
A distance makes sense for merging vertices, but I'm not sure how it applies to determining whether or not two triangles should be merged. Their normal vectors would have to be very close, and they would have to share two vertices, and I suppose there would have to be a set of 3 vertices that form a straight line, give or take some tolerance.
E.g.
Inline Image:
http://catmanofiowa.com/RSoul/img/angles.jpgThese triangles share vertices 1 and 2. If 3 1 and 4 (or 3 2 and 4) form a straight line presumably the two triangles will be merged. Maybe it uses the angle (highlighted) to work out if they're close enough, or some other calculation.
Looks like I'm going to use a default of -ep0, which looks like "don't merge anything" but with an option to change it if people want to experiment.
caffeinatedzombeh on 17/6/2019 at 18:03
Looking at the output in your pictures where 1 really was roughly in line with 3 and 4 I think what it did was go "if we merged those two to give 3,2,4 would that still be the same shape as it was?"
so is 1 collinear to 3 and 4 and is it coplanar to the resulting merged triangles
so is the normal distance of 1 from the line 3,4 less than or equal to -el? and is the normal distance of 1 to the plane 3,2,4 less than or equal to -ep
Was that a single vertex in the .e file you fed it? or did it come out as multiple coincident verts, one per triangle? (I forget how all of this stuff works, I've not worked with these tools for years :( ) I have a feeling it supports both and you may get different results?
It's certainly treated it as multiple vertices that happen to be in the same place or it wouldn't have torn your mesh like that.
I reckon if you set el and ep both to 0 it'd leave your mesh alone, or if you build knowing it's going to do that and merge 1 with the vert to the left of that in your new picture then it'll leave it like that.
I think the tools were originally designed specifically to stop you making a big plane subdivided to give higher lighting resolution as the hardware at the time wouldn't appreciate that.
gamophyte on 4/7/2019 at 19:48
dang Kevel's wife is piiiist
PinkDot on 4/7/2019 at 21:39
Quote:
I don't think I want this to happen, so I won't be doing that again.
I squeeze my eyes and I try to imagine, that these stone looking triangles are actually part of the mesh with a different material applied and I'm thinking to myself... damn good job with the texture alignment! It gives a complete illusion of transparency! ;) :)