POV-Ray : Newsgroups : povray.tools.general : How to "roundify" objects Server Time
28 Mar 2024 22:02:43 EDT (-0400)
  How to "roundify" objects (Message 9 to 18 of 18)  
<<< Previous 8 Messages Goto Initial 10 Messages
From: Stephen
Subject: Re: How to "roundify" objects
Date: 19 May 2015 11:11:43
Message: <555b52af$1@news.povray.org>
On 19/05/2015 15:41, Lars Rohwedder wrote:
> Am 19.05.2015 um 15:32 schrieb Stephen:
>> On 19/05/2015 13:39, Lars Rohwedder wrote:
>>> * strong blur that distorts the whole object a lot but looks
>>> interesting, too.
>>
>> You might find Bill's macro interesting too.
>>
>>
http://lib.povray.org/searchcollection/index2.php?objectName=meshrelief&version=1.0&contributorTag=Bill
>
> Looks nice. (I pimped the example file that is shipped with Bill's macro)
>
> Albeit it does solve the problem I described.
>

It does? I've not used it myself but I remember when Bill made it.

> And I don't know how to generate (either by Povray macro magic or by a
> self-written C++ program) a mesh that represents "rounded" versions of
> arbitrary objects. :-/
>

Neither would I. If I wanted to round a mesh manually. I would subdivide 
it using PoseRay.
It doesn't help though. It doesn't have those command line options. Or 
you could have run it through PovRay.

> Lars R.
>


-- 

Regards
     Stephen


Post a reply to this message

From: Le Forgeron
Subject: Re: How to "roundify" objects
Date: 19 May 2015 11:33:53
Message: <555b57e1@news.povray.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Le 19/05/2015 16:41, Lars Rohwedder a écrit :
> Am 19.05.2015 um 15:32 schrieb Stephen:
>> On 19/05/2015 13:39, Lars Rohwedder wrote:
>>> * strong blur that distorts the whole object a lot but looks 
>>> interesting, too.
>> 
>> You might find Bill's macro interesting too.
>> 
>> http://lib.povray.org/searchcollection/index2.php?objectName=meshreli
ef&version=1.0&contributorTag=Bill
>
>> 
> Looks nice. (I pimped the example file that is shipped with Bill's
> macro)
> 
> Albeit it does solve the problem I described.
> 
> And I don't know how to generate (either by Povray macro magic or
> by a self-written C++ program) a mesh that represents "rounded"
> versions of arbitrary objects. :-/
> 

You would need something like a proximity pattern/evaluator, and to
know if the normal at each vertex is toward inside or outside. For
proximity at 50%, you do not move. For other values, you move along
the normal... excepted that there is more than one normal per vertex,
so you need to average them all somehow (weight might not be trivial,
hoping they are all on the same side).

For proximity giving a low density, you move "inward" (erosion).
For proximity giving a high density, you move "outward" (filling hole)

The problem that remains: getting the initial mesh that satisfies the
needed predicats.

> Lars R.
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iJwEAQEIAAYFAlVbV+IACgkQhKAm8mTpkW1SOQQAupUjpoLY6AtDssid9dmJRY6C
DbXiRdsOKCQF9lIw24YU+PHnTbiMZalYdYqZGqjSskkVZE4OuCG2mClXvCYOR0as
cXF7tQ/pzHmmX9ZFPusmT5lxq83wY5GkiSPm5vz8WwnN6o+ZPpgd+s0mwYifHPUv
HNGIKxgjJc9iPoTqscU=
=pqiz
-----END PGP SIGNATURE-----


Post a reply to this message

From: Lars Rohwedder
Subject: sorry, it does _not_ solve the problem. ;-(
Date: 20 May 2015 03:08:43
Message: <555c32fb@news.povray.org>
>> Albeit it does solve the problem I described.
>>
> 
> It does? I've not used it myself but I remember when Bill made it.

Sorry… it does _not_.  typo by me.


Post a reply to this message

From: Bill Pragnell
Subject: Re: sorry, it does _not_ solve the problem. ;-(
Date: 20 May 2015 03:35:05
Message: <web.555c38b8a77d0b865b7d07940@news.povray.org>
Lars Rohwedder <rok### [at] gmxde> wrote:
> >> Albeit it does solve the problem I described.
> >>
> >
> > It does? I've not used it myself but I remember when Bill made it.
>
> Sorry… it does _not_.  typo by me.

Alas, it was intended to be used on pre-rounded CSG to produce meshes for
surface perturbation. I mostly use it for making weathered bricks, or boulders.
Nice to see it wheeled out though :)

I have never found a satisfactory solution to the general rounding problem.
Isosurface blobs are good, but isosurfaces take so long to render. Extensive
macros for CSG, or hand-modelled meshes seem the best value for time vs
results...


Post a reply to this message

From: Stephen
Subject: Re: sorry, it does _not_ solve the problem. ;-(
Date: 20 May 2015 04:17:15
Message: <555c430b$1@news.povray.org>
On 20/05/2015 08:33, Bill Pragnell wrote:
> Lars Rohwedder <rok### [at] gmxde> wrote:
>>>> Albeit it does solve the problem I described.
>>>>
>>>
>>> It does? I've not used it myself but I remember when Bill made it.
>>
>> Sorry… it does _not_.  typo by me.
>

Good, I was beginning to doubt my sanity. ;-)

> Alas, it was intended to be used on pre-rounded CSG to produce meshes for
> surface perturbation. I mostly use it for making weathered bricks, or boulders.
> Nice to see it wheeled out though :)
>
I didn't really mean it as a solution for Lars.
I was looking for a memory of macros that was used to distress columns. 
When I came across yours. The threads were posted at least five years 
ago and Jim Charter's name springs to mind.

> I have never found a satisfactory solution to the general rounding problem.
> Isosurface blobs are good, but isosurfaces take so long to render. Extensive
> macros for CSG, or hand-modelled meshes seem the best value for time vs
> results...
>
>
Me too. Either hand made or using Blender.

-- 

Regards
     Stephen


Post a reply to this message

From: Lars Rohwedder
Subject: AFAIK it should be integrated in Povray
Date: 21 May 2015 04:05:54
Message: <555d91e2$1@news.povray.org>
> I have never found a satisfactory solution to the general rounding 
> problem. Isosurface blobs are good, but isosurfaces take so long to 
> render. Extensive macros for CSG, or hand-modelled meshes seem the 
> best value for time vs results...

My rough idea:

There is already a function that returns whether a vieving ray "hits"
the surface of a given object's surface (and where it hits). I assume
this function is used in the render core of Povray, too.

So it should be possible to provide another function that returns the
point where the distance between ray and object is 0, but where it has a
given distance 'd'.

Rendering using that function should result in "puffed-up" objects, so
you have to shrink your objects by 'd' before (which can be done by the
Povray core automatically, too. AFAIK)

I think the question whether this is possible should go to the Povray
core developer, not the tool developer. So: Wrong newsgroup... ;-(

Lars R.


Post a reply to this message

From: Le Forgeron
Subject: Re: AFAIK it should be integrated in Povray
Date: 21 May 2015 13:06:18
Message: <555e108a$1@news.povray.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Le 21/05/2015 10:05, Lars Rohwedder a écrit :
>> I have never found a satisfactory solution to the general
>> rounding problem. Isosurface blobs are good, but isosurfaces take
>> so long to render. Extensive macros for CSG, or hand-modelled
>> meshes seem the best value for time vs results...
> 
> My rough idea:
> 
> There is already a function that returns whether a vieving ray
> "hits" the surface of a given object's surface (and where it hits).
> I assume this function is used in the render core of Povray, too.
> 
> So it should be possible to provide another function that returns
> the point where the distance between ray and object is 0, but where
> it has a given distance 'd'.

- From the intersection point, assuming the normal is known at that
point (usually, but not always, brutal change of surface would remain
problematic), you can use a basic trigonometry with the angle between
the ray and the normal to compute the projection of d along the normal
on to the ray so as to get that point. As long as the ray is not
perpendicular to the normal at the intersection point.

So, run the first function, and adjust the intersection.

But with d>0, you will miss the part when the ray does not intersect
the object, yet is near enough that it would intersect with the
adjusted version.

It might be more usable with d<0, using that computation to make the
object appearing smaller. (and keeping the new intersection only if
the point is still "inside" the model object)



> 
> Rendering using that function should result in "puffed-up" objects,
> so you have to shrink your objects by 'd' before (which can be done
> by the Povray core automatically, too. AFAIK)

scale is not shrink.

Consider a torus (major = 4, minor = 1), shrink by d is another torus
(major = 4, minor = 1-d), that's something you cannot achieve via scale.


> 
> I think the question whether this is possible should go to the
> Povray core developer, not the tool developer. So: Wrong
> newsgroup... ;-(
> 
> Lars R.
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iJwEAQEIAAYFAlVeEIsACgkQhKAm8mTpkW1X+wQAvTLp1oQcpdhSQwWYuXHUntpD
JAoN+8fCMopeseMiANL1wEE83di3qMgR4vS8votGjvd/Q1xSyJ7DibtgGZWAu0sW
+GJrd+3X6yT4mczi2BGOLnqlm+W25tn6W8pr0yzJzvdAFcaV7ZCt1OmKf8f7Jiwa
2BX7fCrL29+zSu/QmGU=
=dufP
-----END PGP SIGNATURE-----


Post a reply to this message

From: clipka
Subject: Re: AFAIK it should be integrated in Povray
Date: 21 May 2015 13:59:18
Message: <555e1cf6$1@news.povray.org>
Am 21.05.2015 um 10:05 schrieb Lars Rohwedder:
>> I have never found a satisfactory solution to the general rounding
>> problem. Isosurface blobs are good, but isosurfaces take so long to
>> render. Extensive macros for CSG, or hand-modelled meshes seem the
>> best value for time vs results...
>
> My rough idea:
>
> There is already a function that returns whether a vieving ray "hits"
> the surface of a given object's surface (and where it hits). I assume
> this function is used in the render core of Povray, too.
>
> So it should be possible to provide another function that returns the
> point where the distance between ray and object is 0, but where it has a
> given distance 'd'.

While that sounds like a neat idea at first, it becomes troublesome as 
soon as you try to implement the corresponding function for all the 
various primitives.

Spheres are ok.
Boxes, yes, you can do that.
Cylinders and cones, too.

Meshes and height fields? Things are starting to get a bit more complicated.

Prisms or lathes based on non-linear splines? Text? Bezier patches? It 
gets ugly here, making these objects as complicated as sphere sweeps 
(which are known to be prone to artefacts).

Isosurfaces? Surprisingly enough, while isosurfaces are the easiest way 
to already get what you are asking for (provided there is a solution to 
the problem at all), determining where the distance between the ray and 
the surface equals 'd' is outright impossible for generic isosurfaces.

Fractals? You must be kidding.


Post a reply to this message

From: Thorsten Froehlich
Subject: Re: AFAIK it should be integrated in Povray
Date: 22 May 2015 07:35:00
Message: <web.555f1405eb5e5a7990f7f1b0@news.povray.org>
Lars Rohwedder <rok### [at] gmxde> wrote:
> > I have never found a satisfactory solution to the general rounding
> > problem. Isosurface blobs are good, but isosurfaces take so long to
> > render. Extensive macros for CSG, or hand-modelled meshes seem the
> > best value for time vs results...
>
> My rough idea:
>
> There is already a function that returns whether a vieving ray "hits"
> the surface of a given object's surface (and where it hits). I assume
> this function is used in the render core of Povray, too.
>
> So it should be possible to provide another function that returns the
> point where the distance between ray and object is 0, but where it has a
> given distance 'd'.
>
> Rendering using that function should result in "puffed-up" objects, so
> you have to shrink your objects by 'd' before (which can be done by the
> Povray core automatically, too. AFAIK)

This algorithm will fail for all rays parallel to the object surface, where the
ray does not hit the surface. A simple example where this becomes important is
an L-shaped corner where the object is the left and bottom side of the L-shape
and the ray runs parallel to the L-spahe on the upper-right quadrant. Obviously
you would want that inner corner rounded, but the surface would never be found.

Thorsten


Post a reply to this message

From: And
Subject: Re: AFAIK it should be integrated in Povray
Date: 23 May 2015 05:05:01
Message: <web.55604262eb5e5a7449d5c170@news.povray.org>
clipka <ano### [at] anonymousorg> wrote:
>
> Isosurfaces? Surprisingly enough, while isosurfaces are the easiest way
> to already get what you are asking for (provided there is a solution to
> the problem at all), determining where the distance between the ray and
> the surface equals 'd' is outright impossible for generic isosurfaces.

Yes, I realize this is very hard when I tried to make a constant 'd' function on
a very simple example "y = ax^2 ".

https://www.flickr.com/photos/131379210@N05/17810168859/in/album-72157653310776535/


Post a reply to this message

<<< Previous 8 Messages Goto Initial 10 Messages

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.