 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Had a bit of an error in how I was handling my harmonic mean function that I
fixed.
Here is a run on a real mesh, and it looks like there may some potential.
For scale, the elephant mesh is approximately 240x220x110. I have run a 500x500
sampling grid over a ~350x350 square. Note:I am using a square that uses the
diagonal corner length of the mesh bounding box, so it tends to end up larger
than it needs to be, but this just easily ensures that I am sampling the whole
object without having to sample the whole image/scene.
The other settings I used were:
normal angle = 75deg;
normal samples = 24;
standardized depth for harmonic mean = 10
-tgq
Post a reply to this message
Attachments:
Download 'trace2.jpg' (77 KB)
Preview of image 'trace2.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Trevor G Quayle" <Tin### [at] hotmail com> wrote:
> Had a bit of an error in how I was handling my harmonic mean function that I
> fixed.
>
> Here is a run on a real mesh, and it looks like there may some potential.
>
> For scale, the elephant mesh is approximately 240x220x110. I have run a 500x500
> sampling grid over a ~350x350 square. Note:I am using a square that uses the
> diagonal corner length of the mesh bounding box, so it tends to end up larger
> than it needs to be, but this just easily ensures that I am sampling the whole
> object without having to sample the whole image/scene.
>
> The other settings I used were:
> normal angle = 75deg;
> normal samples = 24;
> standardized depth for harmonic mean = 10
>
> -tgq
This looks very promising, Trevor.
How's it look with the elephant turned y*45, and with some sort of shading?
(i.e., other than the white and grime). Just wondering if the occlusion still
works at some arbitrary angle to the camera...
-------------------------------------------------
www.McGregorFineArt.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Robert McGregor" <rob### [at] mcgregorfineartcom> wrote:
> This looks very promising, Trevor.
>
> How's it look with the elephant turned y*45, and with some sort of shading?
> (i.e., other than the white and grime). Just wondering if the occlusion still
> works at some arbitrary angle to the camera...
Thanks. It should work at any angle, as I am basically tracing rays directly
from the camera itself to only test the visible parts. Right now, the way it is
set up, if I shoot rays from a different location than the camera, you would se
where it is not test (backside) same with if I had reflections. I am just
using a faked raytrace method for testing purposes.
What I would intend to do is try to find a way to implement in the code itself
where it would use the traced rays themselves (similar to AO).
Shading isn't properly implemented at the moment either, as I haven't figured
out how to implement the results as a pigment, so right now it is just tiny
coloured shperes, though I do intersect them with the base object to try to
maintain the surface somewhat.
It really isn't what I would classify as occlusion: I am tracing rays from the
surface of the object at a given angle from the normal and testing for self
intersection.
I still have lots of things to test and work out (not to mention trying to
figure out POV compiling perhaps at some point in time).
One thing I am thinking about trying is adaptive subsampling.
-tgq
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 03/14/2011 09:01 PM, Trevor G Quayle wrote:
> One thing I am thinking about trying is adaptive subsampling.
when the next release comes out there will be a couple of sample scenes
in ~scenes/camera/mesh_camera/ess/ ... but here's a preview:
http://www.adamcrume.com/blog/
this example is orthographic camera but the author has also contributed
a perspective camera version as well
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Another test on a more complex mesh object. Here I have run 3 different
instances. Note each one has to be run separately and translated/rotated before
running the algorithm, otherwise the untraced areas would be visible.
Here the general object size is 200units high. Crevice checking is done for a
control depth of 15units, normal angle of 75deg, 16 traces per point.
I also changed the object I am using to show my crevice solouring, I am now
using mesh 'pixels' that extend back into the camera point (mesh because they
are a 4-sided pyramid of sorts), but intersected with the base object. This way
I get a sharp transition from each pixel, with no overlap. One downfall of this
is that I have to texture my base object after using it in the grime (or use an
untextured instance) as the intersection CSG operation causes my grime pixel to
adopt the base object texture otherwise.
The grime is a little pixelated here, because my general pixel size is ~2x that
for the image resolution.
-tgq
Post a reply to this message
Attachments:
Download 'trace3.jpg' (113 KB)
Preview of image 'trace3.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 03/15/2011 01:17 PM, Trevor G Quayle wrote:
> Another test on a more complex mesh object. Here I have run 3 different
> instances. Note each one has to be run separately and translated/rotated before
> running the algorithm, otherwise the untraced areas would be visible.
>
> Here the general object size is 200units high. Crevice checking is done for a
> control depth of 15units, normal angle of 75deg, 16 traces per point.
>
> I also changed the object I am using to show my crevice solouring, I am now
> using mesh 'pixels' that extend back into the camera point (mesh because they
> are a 4-sided pyramid of sorts), but intersected with the base object. This way
> I get a sharp transition from each pixel, with no overlap. One downfall of this
> is that I have to texture my base object after using it in the grime (or use an
> untextured instance) as the intersection CSG operation causes my grime pixel to
> adopt the base object texture otherwise.
>
> The grime is a little pixelated here, because my general pixel size is ~2x that
> for the image resolution.
>
> -tgq
hey wow ... making some progress! Did they link I put up spark an idea?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> hey wow ... making some progress! Did they link I put up spark an idea?
Thanks. No not yet. Still working at some other tweaks of my testing before
adding some subsampling. I do have some ideas for what I want to try for
sub-sampling. There are two different levels:
1) grid sampling level - rather specifying my starting grid size with a large
resolution, I may try smaller and have it subsample based on intersections.
2) number of crevice traces shot - with this, I would specify a base level (say
4 at 90deg spacing) and then subsample based on intersections found
Of these, #2 is the easiest and most applicable perhaps. The first item is for
my current scene level testing only where I have to manually set and run the
traces. The idea would eventually be that it is a pattern in the code that uses
the camera rays themselves. In this case, any resolution subsampling required
would be probably handled by AA settings.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
A quick little posting exhibiting the effects of two of the parameters.
For reference, the model is 200 (units) high. Again I have used coarser
resolution for speed purposes which is what makes it look pixelly (grime
'pixels' are larger than image pixels).
The top left is the main control image with a setting of:
control depth = 5 (units), normal angle = 60 (degrees)
the remaining 4 images on the left side retain the normal angle of 60, but
increase control depth: 20, 50, 100 & 200
the 5 images on the left side retain the control depth of 5, but increase normal
angle: 65, 70, 75, 80 & 85.
A few effects can be noted:
-the size of the control depth effects how large of crevice widths effect the
grime build-up. We can see that the shallow patterns on the back don't get
picked up, but more open or larger areas get affected (e.g. underside of model)
-increasing control depth also affects the value of the grime deeper in the
crevice
-changing the normal angle effects how shallow crevices effect the grime
build-up. This time we can see with shallower (greater) angles, the shallow
patterns on the back start to get picked up. However in more wide open areas,
we don't see the grime build-up (e.g. underside of model again)
with the very shallow angle (85), the whole model gets affected. I don't know
whether this is picking up very minor indentations, but it looks more like it is
a result of the model mesh resolution
More to do, but this is looking pretty satisfying at present.
-tgq
Post a reply to this message
Attachments:
Download 'trace9.jpg' (640 KB)
Preview of image 'trace9.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Trevor G Quayle" <Tin### [at] hotmailcom> wrote:
> Another test on a more complex mesh object. Here I have run 3 different
> instances. Note each one has to be run separately and translated/rotated before
> running the algorithm, otherwise the untraced areas would be visible.
>
> Here the general object size is 200units high. Crevice checking is done for a
> control depth of 15units, normal angle of 75deg, 16 traces per point.
>
> I also changed the object I am using to show my crevice solouring, I am now
> using mesh 'pixels' that extend back into the camera point (mesh because they
> are a 4-sided pyramid of sorts), but intersected with the base object. This way
> I get a sharp transition from each pixel, with no overlap. One downfall of this
> is that I have to texture my base object after using it in the grime (or use an
> untextured instance) as the intersection CSG operation causes my grime pixel to
> adopt the base object texture otherwise.
>
> The grime is a little pixelated here, because my general pixel size is ~2x that
> for the image resolution.
>
> -tgq
Nice, this is really starting to come together, looking good. What's the parse
time for the grime algorithm per head mesh here?
-------------------------------------------------
www.McGregorFineArt.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Nice, this is really starting to come together, looking good. What's the parse
> time for the grime algorithm per head mesh here?
I am using very low testing settings so I can get quick results, but parsing
depends on the sample resolution, and number of normals traced. On my home
machine, with res set to 400, number of trces set to 32, this parsed in
~30seconds, including ~7seconds to load the mesh (~35MB). Rendering is another
40secs on top of that, mostly because of all the intersections for each
grime-pixel. I've been think about a way to try to make a procedural texture
out of it rather than the current method.
-tgq
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
