gdalgorithms-list

[Algorithms] Sampling vs fitting values over vertices

[pete d. <pb...@po...>]

Our engine (I presume, like many others) stores some lighting/misc data 
per mesh vertex that would really be best stored in a texture.  This 
works reasonably well and in itself doesn't bother me terribly, but the 
fact that we sample the values at the vertex itself does.  The 
artifacts, ie the occasional dark tri due to occlusion at the verts 
being much darker than the average over the face, are something our 
artists have gotten used to painting out.  But I'd hope we could give 
much better baseline results.

So instead of simply sampling at vertices, I was planning on generating 
samples on each face (probably somewhat uniformly over the outside area 
of the mesh) and fitting (least squares) for the vertex values.  Ie try 
to minimize the actual deviation of the interpolated values over the 
face from what they should be, instead of simply ignoring the fact that 
they'll be interpolated..  And in additional to accuracy, it should let 
us handle hard edges, doublesided tris and a few more situations more 
accurately than they are now.

I presume people have done this before, so before trying it out I 
thought I'd ask if anyone had positive results, rules of thumb about how 
dense data needs to be sampled to generate good results in most cases, 
if applying a similar scheme to additionally generate gradients wrt u&v 
gives compelling improvements, etc.  Searching on the web/archive didn't 
really find too much (besides D3DX PRT methods that don't say how they 
work, and still require a texture thus an atlas/usable parameterization, 
which I don't really want to deal with).  Thanks for any input!

Pete

Re: [Algorithms] Sampling vs fitting values over vertices

[Bert P. <be...@bp...>]

This sounds like a standard sampling problem, so all of the literature
with regards to sampling, aliasing, undersampling, filtering and
reconstruction could be helpful? (including a thread IIRC about it
either here or on SWeng)

Ie. that may tell you how many samples you need to be artefact
free, how to best position and maybe subdivide them, using gradients
for better reconstruction, adding a good filter, etc.


> gives compelling improvements, etc.  Searching on the web/archive didn't 
> really find too much (besides D3DX PRT methods that don't say how they 
> work, and still require a texture thus an atlas/usable parameterization, 
> which I don't really want to deal with).

PRT solves an undersampling problem, but a different one; instead of
figuring out what the best lighting params are for a vertex to
accurately represent a face, it figures out what the best lighting
params are for representing the entire incoming radiance (cosine
convolved, optionally bounced/scattered) at the sample location.

It can be done per vertex, in which case it doesn't need a UV mapping,
but then it can suffer artefacts from interpolation or unfortunate
sample locations again; hence it solves a related but different problem
and wouldn't solve your issue (other than smoothing things out perhaps
and thus being less vulnerable to it).


hth,
bert

Re: [Algorithms] Sampling vs fitting values over vertices

[pete d. <pb...@po...>]

Without getting too OT and talking about D3D...!  I was not referring to 
PRT per se but of the texture->vertex resampling method it provides: 
ID3DXPRTEngine::ResampleBuffer (which could do something smarter than 
filter the texture around the vert's uv).   A smarter, probably ad-hoc 
method to generate samples and generate/fit per-vertex values is what I 
am after -- I can't afford the compute time to do a proper job sampling 
(needless to say our function is not analytic, is expensive to compute 
and is at times hard to analyze) or even fill out and then filter a 
chart where there is reasonable coverage.

I'll rephrase my question a little.. Do folks who do something more 
clever than straight up point/supersampling to generate per-vertex data 
(like fitting based on error between interpolated and reference values 
or proper/ad-hoc sampling) get compellingly better results than those 
after the occasional touch up by an artist?  Or do you just use what 
comes out of Maya/Max/whatever?  Likewise with solving for and using 
gradients when you want to spend the memory and time (I've had mixed 
experiences with their cost/benefit at times so don't have a good guess 
if they'll be worth it).  Apologies if this isn't algorithmy enough.. 
maybe we could analyze the structure of the matrix to solve based on 
connectivity of the mesh! :)

>> gives compelling improvements, etc.  Searching on the web/archive didn't 
>> really find too much (besides D3DX PRT methods that don't say how they 
>> work, and still require a texture thus an atlas/usable parameterization, 
>> which I don't really want to deal with).
>>     
>
> PRT solves an undersampling problem, but a different one; instead of
> figuring out what the best lighting params are for a vertex to
> accurately represent a face, it figures out what the best lighting
> params are for representing the entire incoming radiance (cosine
> convolved, optionally bounced/scattered) at the sample location.
>
> It can be done per vertex, in which case it doesn't need a UV mapping,
> but then it can suffer artefacts from interpolation or unfortunate
> sample locations again; hence it solves a related but different problem
> and wouldn't solve your issue (other than smoothing things out perhaps
> and thus being less vulnerable to it).
>
>   

Thanks!

Pete