 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Trevor G Quayle" <Tin### [at] hotmail com> wrote:
> Had a look at addressing the issue I was having with shallow angles picking up
> ridges. I did some testing and found that this is a result of how trace works
> (on smooth meshes in particular). The intersection returned is the intersection
> with the flat, unsmoothed surface of the mesh (unperturbed), whereas the surface
> normal returned is based on the smoothed surface normal at the point. What
> happens is that very shallow traces end up intersecting with the mesh in some
> locations, particularly close to triangle edges.
>
> Following my simple solution #5, I added this capability into my current macro
> with good results. See the attached image. For reference, the model is 200
> units high, normal angle set to 85, control depth set to 20. The first image is
> run with no offset. Distinct artifacts and mesh lines can be seen, particularly
> the lines along the body and legs. The second image uses the same parameters
> but with a offset of 0.1 with fairly favourable results.
>
> -tgq
Sorry to bore you all with my testing details...
Tested this modification again with my elephant model. This is a good model as
it has very shallow details carved into it, but was showing up very dirty with
artifacts at low angles.
Model height = 200
Control depth = 20
Normal angle = 85
The first image is with no surface offset. The results are very dirty and
contaminated with lots of artifacts.
The second image uses an offset of 0.1 with very much improved results.
One thought and spin-off of this is that I have been thinking I may be able to
adapt this for outside corners/ridges for wearing.
-tgq
Post a reply to this message
Attachments:
Download 'elefunk.jpg' (165 KB)
Preview of image 'elefunk.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 17.03.2011 14:52, schrieb Trevor G Quayle:
>>> One thing I noticed is that with interpolate 1 there is a distinct shift down
>>> and to the left. Is there a bias in the internal interpolate function? This is
>>> something that I have noticed before with interpolate.
>>
>> It was known (and fixed) for interpolation of input images, but has
>> never been examined for df3 files yet.
>
>
> I ran a test with a 1/2 pixel shift which corrected it, so it does look like
> this just needs to be corrected for df3 files in the code.
I had a closer look by now; according to the code, there is indeed a
half-voxel shift towards negative coordinate values, for both trilinear
and tricubic interpolation.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 17.03.2011 16:00, schrieb Trevor G Quayle:
> 1) have the trace function return the perturbed intersection point, not the
> triangle surface: this would have to be done in the POV source. I imagine this
> is difficult if not nearly impossible, hence we still get the shadow line issue
> with meshes. Not likely solution at present.
At present, POV-Ray does not have any code to compute such a thing as a
"pertubed intersection point".
> 2) have the trace function return the unperturbed normal at the intersection:
> again this would have to be done in the POV source and would be much simpler, if
> not trivial to do compared to 1. However this would change the way trace works
> and, in most situations, may not be desirable, and could break older scenes.
> Not likely solution.
While indeed being simpler than 1), the changes would still be
non-trivial; however, virtually all of the necessary changes should be
done anyway sooner or later to address some issues with smooth meshes,
triangles and height fields.
(Internally, POV-Ray is currently aware of two different normal vectors:
The "pertubed" normal vector after applying "normal{}" blocks, and a
"raw" normal vector as specified by geometry, /after/ "fake smoothing"
where applicable (e.g. smooth meshes). For certain computations the true
non-smoothed geometric normal would be better suited though, so in the
long run POV-Ray should be made aware of this as a third normal.)
And yes, changing the behaviour of trace() could indeed break older scenes.
> 3) manual method of 2), have two instances of the mesh used, one smoothed, one
> not. the smoothed one gets used for rendering, the unsmoothed for tracing: Not
> an elegant solution as it requires creating and loading two separate instances
> of the same mesh.
... but possible without any modifications to the POV-Ray code.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
A general update on some latest experiments. I played with adding in recusive,
adaptive subsampling to help speed things up a little bit. This was only done
for the number of sample traces run around each intersection point: start with a
minimum number of traces, if intersections are found, recurse to additional
traces until the maximum depth or confidence level is reached
Three variables get set:
1) minimum recursion depth
2) maximum recursion depth
3) confidence level
Both minimum and maximum recursion depth are 2^x values so (0=1, 1=2, 2=4, etc)
usually I would always set minimum to 2 which means 4 samples are traced at
0,90,180 & 270 degrees. Confidence is based on the percent change of the
returned value from one recursion level to the next.
As a sample I ran my elephant model through it. The general numbers:
model height: 200 (bounding box 313 diagonal)
resolution: 500 (based on bounding box diagonal)
control depth: 15
control angle: 85
surface offset: 0.05
At this resolution, 251,001 initial traces are sent (501x501). Of these, 55,024
succeed in hitting the object (22%). This is expected because of how I am
choosing my sample grid size: given a general object size of 200 units, and a
grid of 313 units means that at best, the model fill ~41% of the grid. This is
something I may yet work on tuning.
For the testing, I used a base maximum depth of 5 (2^5 = 32 samples). At this
depth, the maximum number of traces possible is 8,032,032 on the full sample
grid (including both object intersection and normal sample traces
251,001+251,001*32), and 2,011,769 based on the successful object trace hits.
1)
min RD = 5
max RD = 5
conf = 1
total traces = 2,011,769 (100%)
parse time 112sec
2)
min RD = 2
max RD = 5
conf = 1
total traces = 1,600,309 (80%)
parse time 97sec (87%)
3)
min RD = 2
max RD = 5
conf = 0.9
total traces = 1,103,477 (55%)
parse time 76sec (68%)
4) for comparison
min RD = 2
max RD = 2
conf = 1
total traces = 471,097
parse time 48sec
Note that there is a difference between 1 & 2 despite a conficence level of 1 as
if no sample intersections are found on the first pass, the algorithm kicks out.
This is not as dramatic an impact as I was hoping for, but it does have some
value in helping with render time.
-tgq
Post a reply to this message
Attachments:
Download 'trac.jpg' (143 KB)
Preview of image 'trac.jpg'
|
|
| |
| |
|
|
|
|
| |
|
|
