 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Thorsten Froehlich" wrote:
> > Crash with no objects in scene
> > http://news.povray.org/3bd985b0@news.povray.org
> > (also reported as http://news.povray.org/3C19B9EA.D2E16FBC@gmx.de
>
> Duplicate of function problem in beta 8. Already fixed in beta 9.
It still crashes on my system using beta 9.
Rune
--
3D images and anims, include files, tutorials and more:
Rune's World: http://rsj.mobilixnet.dk (updated Nov 5)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3C307740.72F654E0@gmx.de> , Christoph Hormann
<chr### [at] gmx de> wrote:
> I understand that, but in most cases it would be perfectly sufficient to
> enable background saving only when a render is running.
>
> BTW, i presume the situation of saving while a scene is being parsed (that
> uses this file) is a problematic case anyway.
When saving goes on in the background the behavior gets unpredictable even
for the developers of the software. I.e. what happens when the user starts
rendering (because the current scene has finished) of the scene file while
saving is still in progress? This would again require the "Start Rendering"
command to be disabled.
In short it would be a usability nightmare and adds nothing but confusion.
POV-Ray GUIs are a kind of IDE, not word processors* :-)
Thorsten
* While some may not see the difference, see the GUI as *independent* from
the renderer. There is no such independent element in word processors.
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c3051bf$1@news.povray.org> , "Thorsten Froehlich"
<tho### [at] trfde> wrote:
> Please also note my recent additions in the Dec 24th list thread.
Regarding:
job000208
with orthographic camera objects disappear when "angle" keyword is used
Analysis:
It turns out this never was a bug. 'angle' works exactly as advertised in
the manual. The problem is the user specified the camera type after the
angle, which assumed it was applied to a perspective camera and consequently
changed the direction vector length, which makes it look like the object
disappears.
Solution in next beta:
Now, with version 3.5 specified the camera type has to be the first thing in
a camera statement. The default type (which obviously does not need to be
specified) is still perspective, of course.
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Thorsten Froehlich" wrote:
> Solution in next beta:
> Now, with version 3.5 specified the camera type has to
> be the first thing in a camera statement. The default
> type (which obviously does not need to be specified)
> is still perspective, of course.
WHAT???
Specifying the orthographic keyword as the last thing in the camera
definition has always been a *very* handy feature which meant you didn't
have to fiddle with the width and height vectors. It's even stated clearly
in the documentation:
"If you add the orthographic keyword after all other parameters of a
perspective camera you'll get an orthographic view with the same image area,
i.e. the size of the image is the same. In this case you needn't specify the
lengths of the right and up vector because they'll be calculated
automatically."
The discussed feature change (not bug fix) would be a *major* brake of
backwards compatibility and would make it much more annoying to work with
the orthographic camera in general. Please don't cripple the software like
that! :(
Rune
--
3D images and anims, include files, tutorials and more:
Rune's World: http://rsj.mobilixnet.dk (updated Nov 5)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wasn't it Thorsten Froehlich who wrote:
>> bug in sphere_sweep for removing parts of an object
>> (discontinuous normals on inverse of sphere_sweep)
>> http://news.povray.org/3C1A5D47.EA38F6E5@amc.uva.nl
>
>Logged as job000200.
Oops. You told me this already, but I mistakenly logged the other bug
that was reported in that article as job000200.
--
Mike Williams
Gentleman of Leisure
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rune <run### [at] mobilixnetdk> wrote:
: Specifying the orthographic keyword as the last thing in the camera
: definition has always been a *very* handy feature which meant you didn't
: have to fiddle with the width and height vectors. It's even stated clearly
: in the documentation:
Who says it will not work like that in the future as well, regardless of
where you put the keyword?
Why should the camera behave differently depending on where you specify
the camera type keyword? IMO the behaviour of the camera should not depend
on this, and thus requiring it to be the first keyword in the camera block
doesn't change anything.
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" wrote:
> Who says it will not work like that in the future
> as well, regardless of where you put the keyword?
Because it doesn't currently?
Specifying the orthographic keyword in the beginning or in the end of the
camera definition gives very different results.
> Why should the camera behave differently depending
> on where you specify the camera type keyword?
Because if you specify it in the end the up and right vectors are
automatically adjusted to match the specified or implied angle of the
corresponding perspective camera.
> IMO the behaviour of the camera should not depend on
> this, and thus requiring it to be the first keyword in
> the camera block doesn't change anything.
Sorry, but I find usability and backwards compatibility more important than
what your opinion is.
Rune
--
3D images and anims, include files, tutorials and more:
Rune's World: http://rsj.mobilixnet.dk (updated Nov 5)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Rune" wrote:
> Sorry, but I find usability and backwards compatibility
> more important than what your opinion is.
I should have phrased that differently...
Anyway, I'll try to make my point more clear.
It's a well known fact that the order in which the parameters of the camera
is specified is important. If you specify the angle after you specify the
direction, the length of the direction vector is adjusted to match the
angle, but if the direction is specified after the angle, the direction is
what counts. Similarly, if the look_at vector is specified after the
direction vector, the direction vector is adjusted, while if the direction
vector is specified after the look_at vector, then the direction overwrites
the look_at vector specified (or something like that).
There are some other such examples, and in general it's rather difficult to
fully understand how all the parameters in the camera interact (I don't
*fully* understand it myself). The documentation helps a lot though, if you
read it thoroughly.
The orthographic keyword is another such case. If it's specified in the
start, then the angle keyword won't make a difference, and the viewing area
can only be controlled with the up and right vectors. But if it's specified
in the end, it will "convert" the perspective camera to an orthographic
camera and take the former angle (specified or implied) into account. I
almost always use the orthographic camera that way because it's much easier.
I would find it a bad choice to change it.
Rune
--
3D images and anims, include files, tutorials and more:
Rune's World: http://rsj.mobilixnet.dk (updated Nov 5)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rune <run### [at] mobilixnetdk> wrote:
:> Why should the camera behave differently depending
:> on where you specify the camera type keyword?
: Because if you specify it in the end the up and right vectors are
: automatically adjusted to match the specified or implied angle of the
: corresponding perspective camera.
Why shouldn't it work so that you specify the 'orthographic' keyword at
the beginning, and subsequent 'angle' or other relevant keywords would change
the right and up vectors as it would be logical?
That is, if you say 'angle whatever', the right and up keywords are
modified to match that. It you say 'right whatever' after that, then the
right keyword is set to that.
: Sorry, but I find usability and backwards compatibility more important than
: what your opinion is.
Backwards compatibility has never been an excuse for maintaining bad
features. This is why backwards compatibility in things like 'halo',
'log', etc was not preserved.
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rune <run### [at] mobilixnetdk> wrote:
: It's a well known fact that the order in which the parameters of the camera
: is specified is important.
I was talking exclusively of the camera type keywords, not the other
parameters.
I don't understand why 'angle' should have no effect if the keyword
'orthographic' is specified at the beginning, but it should have some
effect if 'orthographic' is specified at the end. Why shouldn't it always
have the same effect regardless of where the 'orthographic' is specified?
: The orthographic keyword is another such case. If it's specified in the
: start, then the angle keyword won't make a difference
This is exactly what I don't understand why it should be so.
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
