I created four new scenes comparing different types of graphical 
projection. You can see the results here:

https://commons.wikimedia.org/wiki/File:Various_projections_of_cube_above_plane.svg

What I did was this:

1. model the scenes in POV-Ray
2. using "screen.inc" export the important points to a text file
3. import the points into GeoGebra
4. connect in GeoGebra the points using segments and polygons
5. export to SVG

This was the easiest way I could think of for creating SVG files using 
perspective projection.

Mike

Post a reply to this message

Attachments:
Download 'wp_graphical_projection_examples_20170504.zip' (160 KB)

Mike Horvath <mik### [at] gmailcom> wrote:
> I created four new scenes comparing different types of graphical
> projection. You can see the results here:
>
> https://commons.wikimedia.org/wiki/File:Various_projections_of_cube_above_plane.svg
>
> What I did was this:
>
> 1. model the scenes in POV-Ray
> 2. using "screen.inc" export the important points to a text file
> 3. import the points into GeoGebra
> 4. connect in GeoGebra the points using segments and polygons
> 5. export to SVG

eek.
I think that some of us have worked out a few rudimentary tools for making SVG
files that mimic some basic lines and shapes.
If and when I have the time and motivation, I could probably pair that with what
I've learned - and haven't forgotten - from the whole view frustum project, and
then use trace() to get screen coordinates.

Maybe a little macro could be worked out that - given the constants for defining
the image plane, the camera, and the viewing vector, would project a set of
given points onto that plane...

> This was the easiest way I could think of for creating SVG files using
> perspective projection.

"... fastest way, using what I had, and what I already knew"
Yep - I often have to do that as an expedient, just to _get it done._

Nice little project though.  :)

> Mike

Post a reply to this message

On 5/4/2017 8:43 AM, Bald Eagle wrote:
> Mike Horvath <mik### [at] gmailcom> wrote:
>> I created four new scenes comparing different types of graphical
>> projection. You can see the results here:
>>
>> https://commons.wikimedia.org/wiki/File:Various_projections_of_cube_above_plane.svg
>>
>> What I did was this:
>>
>> 1. model the scenes in POV-Ray
>> 2. using "screen.inc" export the important points to a text file
>> 3. import the points into GeoGebra
>> 4. connect in GeoGebra the points using segments and polygons
>> 5. export to SVG
>
> eek.
> I think that some of us have worked out a few rudimentary tools for making SVG
> files that mimic some basic lines and shapes.
> If and when I have the time and motivation, I could probably pair that with what
> I've learned - and haven't forgotten - from the whole view frustum project, and
> then use trace() to get screen coordinates.
>
> Maybe a little macro could be worked out that - given the constants for defining
> the image plane, the camera, and the viewing vector, would project a set of
> given points onto that plane...
>
>> This was the easiest way I could think of for creating SVG files using
>> perspective projection.
>
> "... fastest way, using what I had, and what I already knew"
> Yep - I often have to do that as an expedient, just to _get it done._
>
> Nice little project though.  :)
>
>> Mike
>
>
>


I forgot that in my version of "screen.inc" I added a macro called 
"Get_Screen_XY" that takes any 3D scene coordinate as input and outputs 
the 2D screen coordinate, normalized between 0 and 1. This makes things 
super simple! I just list whatever points I want to project, and then 
write the 2D locations to a text file.

I've attached "screen.inc" to this post.

Mike

Post a reply to this message

Attachments:
Download 'utf-8' (8 KB)

I used a similar strategy when creating this image:

https://commons.wikimedia.org/wiki/File:Graphical_projection_comparison.png

The main image was rendered in POV-Ray. I then converted the important 
coordinates from 3D to 2D, and built the arrows and text on top using 
GeoGebra.


Mike

Post a reply to this message

The instructions say:

> You can only use screen.inc with the perspective camera.

Note that this is no longer the case. I added a macro called 
"Set_Camera_Orthographic" that allows you to use a parallel camera as 
well. I will need to update the text to reflect this.


Mike

Post a reply to this message

Mike Horvath <mik### [at] gmailcom> wrote:

>
> I forgot that in my version of "screen.inc" I added a macro called
> "Get_Screen_XY" ...

Yeah, I was perplexed as to how the 'vanilla' version of screen.inc could do
that.

This looks interesting. Thanks for posting your modified version.

Post a reply to this message

Mike Horvath <mik### [at] gmailcom> wrote:

> I forgot that in my version of "screen.inc" I added a macro called
> "Get_Screen_XY" that takes any 3D scene coordinate as input and outputs
> the 2D screen coordinate, normalized between 0 and 1. This makes things
> super simple!

Hmmm.  I recall that Screen.inc uses a -0.5 to +0.5 range.
Might you want to edit "Get_Screen_XY" to output THAT range, so that it would be
easy to align things on the screen with objects in the image,
and then rename the "Get_Screen_XY" to "Get_Image_XY" - since that might
disambiguate things a bit?

I suppose if you're ambitious enough - you could flip those macros around and
given a distance from the camera-right-up plane, you could return x,y,z
coordinates to place an object into the scene, so that it would line up with a
place on the screen or in the image.

> I just list whatever points I want to project, and then
> write the 2D locations to a text file.

Since the SVG is just a text file, and you can clearly follow the syntax - why
not just write the SVG header, output an SVG line definition, and add some
triangles or whatnot, and get your usable SVG straight from POV-Ray?
It would cut out a lot from the workflow.
Just a suggestion.

> I've attached "screen.inc" to this post.

Thank you :)

One thing that might be useful is to include some reminders and usage info for
output to the debug stream.
I often
#declare Verbose = true;
in my scene, and then any macros or parts of the scene where I want to get data
from check for that variable and then I get everything I want with just one
"switch".

I do the same thing with any weird command syntax that I use - I just output or
include in the comments a working line of code using that command.

Post a reply to this message

On 5/4/2017 12:44 PM, Bald Eagle wrote:
> Mike Horvath <mik### [at] gmailcom> wrote:
>
>> I forgot that in my version of "screen.inc" I added a macro called
>> "Get_Screen_XY" that takes any 3D scene coordinate as input and outputs
>> the 2D screen coordinate, normalized between 0 and 1. This makes things
>> super simple!
>
> Hmmm.  I recall that Screen.inc uses a -0.5 to +0.5 range.
> Might you want to edit "Get_Screen_XY" to output THAT range, so that it would be
> easy to align things on the screen with objects in the image,
> and then rename the "Get_Screen_XY" to "Get_Image_XY" - since that might
> disambiguate things a bit?
>

I just checked the code again and realized the output is not normalized 
to between 0 and 1. Instead, it outputs a fraction of whatever 
image_width and image_height are. Switching back to -0.5 to +0.5 should 
be easy.


> I suppose if you're ambitious enough - you could flip those macros around and
> given a distance from the camera-right-up plane, you could return x,y,z
> coordinates to place an object into the scene, so that it would line up with a
> place on the screen or in the image.
>

I can't really remember the details of how the code works. It's been so 
long since I looked at this code. If you want to take a crack at it, go 
ahead.


>> I just list whatever points I want to project, and then
>> write the 2D locations to a text file.
>
> Since the SVG is just a text file, and you can clearly follow the syntax - why
> not just write the SVG header, output an SVG line definition, and add some
> triangles or whatnot, and get your usable SVG straight from POV-Ray?
> It would cut out a lot from the workflow.
> Just a suggestion.
>

I would have to rewrite this code for every scene I create. What if I 
want to change the colors? What if I want to add some text? Angle or 
distance measurements? Buttons and check boxes? This all means extra 
work compared to GeoGebra, which is WYSIWYG.


>> I've attached "screen.inc" to this post.
>
> Thank you :)
>
> One thing that might be useful is to include some reminders and usage info for
> output to the debug stream.
> I often
> #declare Verbose = true;
> in my scene, and then any macros or parts of the scene where I want to get data
> from check for that variable and then I get everything I want with just one
> "switch".
>
> I do the same thing with any weird command syntax that I use - I just output or
> include in the comments a working line of code using that command.
>

I don't think I modified the debug text from the original. This is all I 
could find:

	#ifdef(View_POV_Include_Stack)	#debug "including screen.inc\n"		#end


Mike

Post a reply to this message

On 5/4/2017 12:44 PM, Bald Eagle wrote:
> I suppose if you're ambitious enough - you could flip those macros around and
> given a distance from the camera-right-up plane, you could return x,y,z
> coordinates to place an object into the scene, so that it would line up with a
> place on the screen or in the image.
>

I checked the code once again, an it may be already possible to do this 
by adjusting the "Scaling" parameter of the "Screen_Object" and 
"Screen_Plane" macros. I might be wrong though.


Mike

Post a reply to this message

Update in the attachment.


Mike

Post a reply to this message

Attachments:
Download 'wp_graphical_projection_examples_20170505.zip' (313 KB)