I think it would be good to have a series of 2D graphical elements to 
use to display on-screen elements like text, arrows, guidelines, etc. 
for creating diagrams and such. But, it would be kind of complicated 
with POV-Ray's existing 3D elements.

Anyone want to help with such a project?

I'm thinking that copying SVG's syntax would be good. Positing them on 
the screen would also be difficult.


-- 
http://isometricland.com

Post a reply to this message

Le 11/02/2011 02:25, SharkD a écrit :
> I think it would be good to have a series of 2D graphical elements to
> use to display on-screen elements like text, arrows, guidelines, etc.
> for creating diagrams and such. But, it would be kind of complicated
> with POV-Ray's existing 3D elements.
> 
> Anyone want to help with such a project?
> 
> I'm thinking that copying SVG's syntax would be good. Positing them on
> the screen would also be difficult.
> 
> 

Flyspray #63 get closed because of lack of answer from OP (guess who
opened it ?) (more about SVG in it!)

Have you investigated the screen.inc from the distribution ?


-- 
Software is like dirt - it costs time and money to change it and move it
around.

Just because you can't see it, it doesn't weigh anything,
and you can't drill a hole in it and stick a rivet into it doesn't mean
it's free.

Post a reply to this message

Le_Forgeron <lef### [at] freefr> wrote:
> Le 11/02/2011 02:25, SharkD a écrit :
> > I think it would be good to have a series of 2D graphical elements to
> > use to display on-screen elements like text, arrows, guidelines, etc.
> > for creating diagrams and such. But, it would be kind of complicated
> > with POV-Ray's existing 3D elements.
> >
> > Anyone want to help with such a project?
> >
> > I'm thinking that copying SVG's syntax would be good. Positing them on
> > the screen would also be difficult.
> >
> >
>
> Flyspray #63 get closed because of lack of answer from OP (guess who
> opened it ?) (more about SVG in it!)
>
> Have you investigated the screen.inc from the distribution ?
>
>
> --
> Software is like dirt - it costs time and money to change it and move it
> around.
>
> Just because you can't see it, it doesn't weigh anything,
> and you can't drill a hole in it and stick a rivet into it doesn't mean
> it's free.

The problem with screen.inc or any other method that places an actual object on
the image, is that it falls apart when using focal blur.
It would be nice to have a way of adding 2D elements to the image that can be
done easily, and are not affected by the camera.

-tgq

Post a reply to this message

Le 11/02/2011 14:36, Trevor G Quayle a écrit :
> Le_Forgeron <lef### [at] freefr> wrote:
>> Le 11/02/2011 02:25, SharkD a écrit :
>>> I think it would be good to have a series of 2D graphical elements to
>>> use to display on-screen elements like text, arrows, guidelines, etc.
>>> for creating diagrams and such. But, it would be kind of complicated
>>> with POV-Ray's existing 3D elements.
>>>
>>> Anyone want to help with such a project?
>>>
>>> I'm thinking that copying SVG's syntax would be good. Positing them on
>>> the screen would also be difficult.
>>>
>>>
>>
>> Flyspray #63 get closed because of lack of answer from OP (guess who
>> opened it ?) (more about SVG in it!)
>>
>> Have you investigated the screen.inc from the distribution ?
>>
>>

> The problem with screen.inc or any other method that places an actual object on
> the image, is that it falls apart when using focal blur.
> It would be nice to have a way of adding 2D elements to the image that can be
> done easily, and are not affected by the camera.

Huh ?
If it is not to be affected by the camera, it will not stand with focal
blur.

Oh! *Some thoughts get into a brain somewhere lost deep in the universe*

if you just want a way to add 2D elements to an image, I would suggest
learning imagemagick script and using the post-render script facility of
povray (does it work yet within 3.7RC3 ?).

Do not ask a 3D renderer to do the job of a 2D picture editor.


-- 
Software is like dirt - it costs time and money to change it and move it
around.

Just because you can't see it, it doesn't weigh anything,
and you can't drill a hole in it and stick a rivet into it doesn't mean
it's free.

Post a reply to this message

Am 11.02.2011 14:36, schrieb Trevor G Quayle:

> The problem with screen.inc or any other method that places an actual object on
> the image, is that it falls apart when using focal blur.
> It would be nice to have a way of adding 2D elements to the image that can be
> done easily, and are not affected by the camera.

There is: Use an SVG tool to convert to rasterized image with alpha 
channel, and use an image processing tool to overlay...

(Hit: There do exist such tools for batch processing, so you can 
instruct POV-Ray to automatically run those after rendering of each frame.)

Remember that POV-Ray is not a swiss army knife for image generation - 
it's a 3D renderer.

Post a reply to this message

Le_Forgeron <lef### [at] freefr> wrote:
> Huh ?
> If it is not to be affected by the camera, it will not stand with focal
> blur.
>
> Oh! *Some thoughts get into a brain somewhere lost deep in the universe*
>
> if you just want a way to add 2D elements to an image, I would suggest
> learning imagemagick script and using the post-render script facility of
> povray (does it work yet within 3.7RC3 ?).
>
> Do not ask a 3D renderer to do the job of a 2D picture editor.
>
>

I wouldn't really ask it to do much, but something I would use it for is
labelling images when I'm running test renders.  Simetimes I do this in batches
and would like paramters used printed directly on the image for reference.  I
know there are other ways to do it, and it can be faked in POV with certain
restrictions.

EG, in these images
(http://news.povray.org/povray.binaries.images/attachment/%3Cweb.4d52afc268e3dc0b81c811d20%40news.povray.org%3E/envmape
x.png)
I used POV to print the note on the bottom for ease (I know I could do it in an
external program).  I can live without it, but it's just something nice to have
available.

As an aside, megaPOV had a "camera_view" pigment, where you can the pigment is a
POV camera.   I used this to make cross-stereo images in one shot: Use an
orthographic camera on a box and texture each half of the box with a slightly
different camera perspective on the actual scene (just had to make sure my box
didn't impede in the scene.  This was also able to be used to do 2D labelling by
reverse: orthographic camera on a box textured with camera pigment, with any 2D
text layered over.



-tgq

Post a reply to this message

Trevor G Quayle wrote:

> The problem with screen.inc or any other method that places an actual object on
> the image, is that it falls apart when using focal blur.

If you want to do this without external tools, you can
separate 2d postprocessing from the actual image rendering
using render 2 passes.

Post a reply to this message

Le_Forgeron <lef### [at] freefr> wrote:
> Huh ?
> If it is not to be affected by the camera, it will not stand with focal
> blur.
>
> Oh! *Some thoughts get into a brain somewhere lost deep in the universe*
>
> if you just want a way to add 2D elements to an image, I would suggest
> learning imagemagick script and using the post-render script facility of
> povray (does it work yet within 3.7RC3 ?).
>
> Do not ask a 3D renderer to do the job of a 2D picture editor.
>
>
> --
> Software is like dirt - it costs time and money to change it and move it
> around.
>
> Just because you can't see it, it doesn't weigh anything,
> and you can't drill a hole in it and stick a rivet into it doesn't mean
> it's free.

The problem with third party tools is that if you are sharing your files you
have to show the users how to set up and use them.

Also, if you make modifications to the original scene, then you have to update
all your 2D images to match it. And you have to do that each time.

Major pain in the a**, IMO.

Post a reply to this message

"Trevor G Quayle" <Tin### [at] hotmailcom> wrote:
> The problem with screen.inc or any other method that places an actual object on
> the image, is that it falls apart when using focal blur.
> It would be nice to have a way of adding 2D elements to the image that can be
> done easily, and are not affected by the camera.
>
> -tgq


I was wondering if the best way were to create geometry (i.e. an intersection of
3D objects with a plane), or to create everything somehow using image maps.

Post a reply to this message

Le_Forgeron <lef### [at] freefr> wrote:
> Flyspray #63 get closed because of lack of answer from OP (guess who
> opened it ?) (more about SVG in it!)

What the heck does this have to do with Flyspray? I'm not making a feature
request.

Post a reply to this message

I guess I should have said "in scene" instead of "on screen". I.e. it should be
possible to place the 2D elements *anywhere* in the scene - not just parallel to
the viewing plane.

Post a reply to this message

Am 07.03.2011 02:29, schrieb posfan12:
> I guess I should have said "in scene" instead of "on screen". I.e. it should be
> possible to place the 2D elements *anywhere* in the scene - not just parallel to

I guess a macro library would be the way to go there. Making the objects 
effectively 2D could be achieved by using an almost-zero depth, or 
intersecting with a simple 2D shape such as a disk or two triangles 
arranged as a square or something.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 07.03.2011 02:29, schrieb posfan12:
> > I guess I should have said "in scene" instead of "on screen". I.e. it should be
> > possible to place the 2D elements *anywhere* in the scene - not just parallel to
>
> I guess a macro library would be the way to go there. Making the objects
> effectively 2D could be achieved by using an almost-zero depth, or
> intersecting with a simple 2D shape such as a disk or two triangles
> arranged as a square or something.

If a true zero depth, 2-D object is desired, then the simplest would probably be
to make the 3D version and intersect it with a 2D box (box with one dimension
zero)

-tgq

Post a reply to this message

Le 2011/03/06 23:59, Trevor G Quayle a écrit :
> clipka<ano### [at] anonymousorg>  wrote:
>> Am 07.03.2011 02:29, schrieb posfan12:
>>> I guess I should have said "in scene" instead of "on screen". I.e. it should be
>>> possible to place the 2D elements *anywhere* in the scene - not just parallel to
>>
>> I guess a macro library would be the way to go there. Making the objects
>> effectively 2D could be achieved by using an almost-zero depth, or
>> intersecting with a simple 2D shape such as a disk or two triangles
>> arranged as a square or something.
>
> If a true zero depth, 2-D object is desired, then the simplest would probably be
> to make the 3D version and intersect it with a 2D box (box with one dimension
> zero)
>
> -tgq
>
>

There IS a zero depth object already available beside the triangle. It's 
called a polygon.
It can have an arbitrary number of edges, receive any pigment, like an 
object pattern for example.

Once created, it can easily be scalled, rotated and mooved around just 
like any other object.

No, a disk is NOT a true 2D object. It have a definite interior just 
like a plane. That interior does extend lateraly beyong the visible part 
and thus will interfere with medias.




Alain

Post a reply to this message

Am 07.03.2011 19:12, schrieb Alain:

> No, a disk is NOT a true 2D object. It have a definite interior just
> like a plane. That interior does extend lateraly beyong the visible part
> and thus will interfere with medias.

Didn't know that. Yuck.

Post a reply to this message

Le 08/03/2011 18:41, clipka nous fit lire :
> Am 07.03.2011 19:12, schrieb Alain:
> 
>> No, a disk is NOT a true 2D object. It have a definite interior just
>> like a plane. That interior does extend lateraly beyong the visible part
>> and thus will interfere with medias.
> 
> Didn't know that. Yuck.

It's a "bug" from the very first days of povray.
Probably a copy-paste of code at that time.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> I guess a macro library would be the way to go there. Making the objects
> effectively 2D could be achieved by using an almost-zero depth, or
> intersecting with a simple 2D shape such as a disk or two triangles
> arranged as a square or something.

What are good candidate 3D objects? They should be smooth and also render fast.

9.2 The ‘rect’ element
9.3 The ‘circle’ element
9.4 The ‘ellipse’ element
9.5 The ‘line’ element
9.6 The ‘polyline’ element
9.7 The ‘polygon’ element

From the W3C:
http://www.w3.org/TR/SVG/shapes.html


Plus the 'path' element, which can be any of:

+ straight lines
+ two types of Bezier curves
+ circular and elliptic arcs



-Mike

Post a reply to this message

Le 12/03/2011 04:40, posfan12 nous fit lire :
> clipka <ano### [at] anonymousorg> wrote:
>> I guess a macro library would be the way to go there. Making the objects
>> effectively 2D could be achieved by using an almost-zero depth, or
>> intersecting with a simple 2D shape such as a disk or two triangles
>> arranged as a square or something.
> 
> What are good candidate 3D objects? They should be smooth and also render fast.
> 
> 9.2 The ‘rect’ element
> 9.3 The ‘circle’ element
> 9.4 The ‘ellipse’ element
> 9.5 The ‘line’ element
> 9.6 The ‘polyline’ element
> 9.7 The ‘polygon’ element
> 

Already seen in FS#63

    * Rectangles can have rounded corners
    * Polygons have last point connected to first

circle = disc
ellipse = disc + scale
polygon = polygon !
rect = flat box, but rounded corners would be a bonus
line = flat box + rotate, but need a pen size!
polyline = sequence of flat box & connecting disc, also need a pen size


> From the W3C:
> http://www.w3.org/TR/SVG/shapes.html
> 
> 
> Plus the 'path' element, which can be any of:
> 
> + straight lines
> + two types of Bezier curves
> + circular and elliptic arcs

Spline! (and it will suck for circular & elliptic arcs)
and you will need a text processing to load the fonts, split each letter
apart and put them along the spline.

Post a reply to this message

Le 2011/03/11 22:40, posfan12 a écrit :
> clipka<ano### [at] anonymousorg>  wrote:
>> I guess a macro library would be the way to go there. Making the objects
>> effectively 2D could be achieved by using an almost-zero depth, or
>> intersecting with a simple 2D shape such as a disk or two triangles
>> arranged as a square or something.
>
> What are good candidate 3D objects? They should be smooth and also render fast.
>
> 9.2 The ‘rect’ element
2 options: 4 sided polygon or very thin box.
The polygon can easily give you a trapeze, parallelogram, or odd quadrangle.
> 9.3 The ‘circle’ element
A disk with hollow
> 9.4 The ‘ellipse’ element
An unevenly scalled disk, also with hollow
> 9.5 The ‘line’ element
A thin and narrow box
> 9.6 The ‘polyline’ element
> 9.7 The ‘polygon’ element
Already exists.
>
>  From the W3C:
> http://www.w3.org/TR/SVG/shapes.html
>
>
> Plus the 'path' element, which can be any of:
Look at the spline.
>
> + straight lines
> + two types of Bezier curves
> + circular and elliptic arcs
>
>
>
> -Mike
>
>

Alain

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:
> > What are good candidate 3D objects? They should be smooth and also render fast.
> >
> > 9.2 The ‘rect’ element
> > 9.3 The ‘circle’ element
> > 9.4 The ‘ellipse’ element
> > 9.5 The ‘line’ element
> > 9.6 The ‘polyline’ element
> > 9.7 The ‘polygon’ element
> >
>
> Already seen in FS#63
>
>     * Rectangles can have rounded corners
>     * Polygons have last point connected to first
>
> circle = disc
> ellipse = disc + scale
> polygon = polygon !
> rect = flat box, but rounded corners would be a bonus
> line = flat box + rotate, but need a pen size!
> polyline = sequence of flat box & connecting disc, also need a pen size


1. I'm not 100% all of these are usable when you take into consideration the
fact that SVG can have separate fill and stroke parameters, several types of
curved and/or boxy "line endings" (can't remember the correct term for
these...), and so on.

2. I've been considering instead using triangle meshes for everything, possibly
using one of the various parametric object approximation macros/tools people
have created over the years. It would make things a lot simpler since you could
just plug in the formulas and have the macros/tools take care of the rest. (In
fact, I think most software that renders SVG in real-time tends to operate in a
manner more similar to this technique.) Of course, the visual quality might be
inferior in several instances, but it is possible in most cases to tweak the
fidelity/granularity with which the objects and formulas are approximated and
replaced by meshes.

Some food for thought.


-Mike

Post a reply to this message