 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
That was my patch. There was (maybe still is) an intermittent and rare bug that
if you stopped the render at just the right time would cause the cache file to
be saved between renders. So what I did was make about 5 hard coded options in
radiosit.c part of the scene language in global settings.
I think some of this may have been fixed, but here's part of the docs I put
together for the patch:
Control of the radiosity cache file is handled with five new keywords. By
default they are (now) all set to 0. You can set them all to one for POV to use
the cache file, which let's you bypass the mosaic preview and also speeds up the
final pass. Leave them off if you are animating and you have an objects
changing, or if you find that changes to the scene file aren't showing up in the
render.
Here's where they belong (not the best keywords I know):
global_settings {
radiosity {
file_savewhilerendering 1
file_readoncontinue 1
file_alwaysreadatstart 1
file_keeponabort 1
file_keepalways 1
}
}
The fix for the broken radiosity problem was to reset Radiosity_Trace_Level to 1
in Deinitialize_radiosity_code() in radio.c.
I don't have the source files for what I did anymore, but I'm pretty sure what I
did was add to parse.c code that would read these parts and save the values into
these members variables:
opts.Radiosity_File_ReadOnContinue = 1;
opts.Radiosity_File_SaveWhileRendering = 1;
opts.Radiosity_File_AlwaysReadAtStart = 0;
opts.Radiosity_File_KeepOnAbort = 1;
opts.Radiosity_File_KeepAlways = 0;
You can find these in povray.c. You could just set them all to 0 and that fixes
the bug. If I were to do this again I would probably just change things so that
the user would specify whether or not to save the file and whether or not to
read it like you have with photon mapping. Having the cache file is a handy
thing if you are just rendering the same scene over and over since it speeds
thing up a bit. If you have it save the file from one scene and then have it
use that file on another scene, you get the radiosity for the previous
one...kind of wierd.
Right now the rad_cache_filename is equal to opts.Scene_Name and
RADIOSITY_CACHE_EXTENSION is defined as .rca in radiosit.h. Perhaps adding an
opts.Radiosity_Cache_File_Name for the user to specify the file and have
rad_cache_filename point to that would be helpful.
Just trying to share all I remember about this in case you want to try doing it.
-Mike
> This reminds me.... A while back somebody said they had changed the
> radiosity code to do a better job of saving/loading the radiosity cache
> file. Now, these changes never made it into POV 3.1g, so I don't have them.
> If this bug is in UVPov, it is probably also in 3.1g. Does anybody have
> that radiosity code? If not, I may be able to make those changes myself,
> but for now I'm sure if you delete that cache file after canceling a trace,
> the problem will go away.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Note to self: Don't render any files called deltree.pov
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 28 Oct 1999 19:12:30 -0700, Ken wrote:
>No we certainly do not want anything like this to happen. If they do start
>happening we will know who to blame... > Nieminen Juha wrote:
Who?
I think I'm the one who posted all the truly scary examples of things
you can do with the stock POV. I had known about them for over a year
and kept them quiet, though, while I waited for enough time to write my
own POV virus to take over the world. So you see, not talking about it
is not a good way to keep it from happening.
--
These are my opinions. I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker wrote in message <38199d2f@news.povray.org>...
>On Thu, 28 Oct 1999 19:12:30 -0700, Ken wrote:
>>No we certainly do not want anything like this to happen. If they do start
>>happening we will know who to blame... > Nieminen Juha wrote:
>
>
>Who?
>
>I think I'm the one who posted all the truly scary examples of things
>you can do with the stock POV. I had known about them for over a year
>and kept them quiet, though, while I waited for enough time to write my
>own POV virus to take over the world. So you see, not talking about it
>is not a good way to keep it from happening.
However, I'm the one who posted the actual virus example.
Mark
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mark Wagner wrote:
>
> Ron Parker wrote in message <38199d2f@news.povray.org>...
> >On Thu, 28 Oct 1999 19:12:30 -0700, Ken wrote:
> >>No we certainly do not want anything like this to happen. If they do start
> >>happening we will know who to blame... > Nieminen Juha wrote:
> >
> >
> >Who?
> >
> >I think I'm the one who posted all the truly scary examples of things
> >you can do with the stock POV. I had known about them for over a year
> >and kept them quiet, though, while I waited for enough time to write my
> >own POV virus to take over the world. So you see, not talking about it
> >is not a good way to keep it from happening.
>
> However, I'm the one who posted the actual virus example.
>
> Mark
But was it not > Nieminen Juha wrote: who originaly raised the concern ?
I believe it was.
--
Ken Tyler - 1100+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nieminen Juha wrote in message <381956bd@news.povray.org>...
>Gilles Tran <tra### [at] inapg inrafr> wrote:
>: I understand the concern about pov viruses
>
> Please don't confuse viruses with trojans.
> A virus is a code that tries to spread itself by attaching itself to
other
>files of the same kind. Usually this infection is intended to be as
invisible
>as possible. Sometimes the virus can do some harm (intentionally or not)
but
>most of the time it tries not to, so that it can spread itself as much as
>possible. Currently I don't know of any reasonable way of making a povray
>virus.
See p.b.s-f for an example virus that would work except for a bug in
POV-Ray. It is anything but invisible!
Mark
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gilles Tran wrote:
> "Jon A. Cruz" wrote:
>
> > Security through obscurity is usually not a good tactic to adopt.
>
> OK, let's formulate it as follows : if you have a house and discover a special
> fun way to go in without using the key, will you put a big sign on the door
> saying "Hey, it's terrible, my door has to be fixed, everybody can go in, and I'm
> going to tell you exactly how to do it because it's soooo cool !". If you really
> think it 's OK to do so, you'd better discuss it with your insurance company...
> You'll just tell your family and other people you trust and report the matter to
> a locksmith. When a security flaw is discovered, the logical tactic is to keep
> quiet and report them discreetly to the people who can fix it, and NOT to educate
> potential intruders. The only time when it may be mandatory to go public in such
> a detailed way is when the people in charge don't care about the problem or don't
> want to know about it, and as far as I know this has not been the case here.
> G.
Well... not quite on target.
Maybe a better analogy would be if you had a garage door opener and trusted its
'secret code' dip switch setting to keep your house safe. Then one day you hear that
if a person throws a simple decade count IC on their remote, they can cycle through
all possible combinations in just a matter of seconds. Then you might realize that
you maybe should take the time to lock the door from your garage to your house when
leaving. Or you could even check with the door opener manufacture to see what
they've done to address the problem.
If you never heard of how to 'get in', you'd never know to take the precaution. But
on the other hand, you can probably be sure that the local gangs would be quite well
aware of this fact once the first person figured it out.
Or for your example, instead of a sign on the door, it would be an article in your
local paper pointing out that if you had brand X windows with a latch by brand Y for
the bay windows, then that can be opened with a simple ball-point pen. You could
then be informed and go look at your windows and if you had the vulnerable
combinations you could either change the latch, or just plant a very spiky plant
under the window. Or get iron security bars welded on.
--
"My new computer's got the clocks, it rocks
But it was obsolete before I opened the box" - W.A.Y.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken <tyl### [at] pacbellnet> wrote:
: But was it not > Nieminen Juha wrote: who originaly raised the concern ?
: I believe it was.
Am I the evil brother now?-)
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ok. Here's the deal: This is not a UVPov vs. Official POV bug, but rather
a MS Visual C++ vs. Watcom bug. I just compiled the official POV 3.1g
source with Visual C++ and it produces the same problem.
Now, you CAN easily get it to work with UVPov. The problem is that the file
is a Unix file (just CR at end of line, not CR+LF). Somehow, the MSVC++
compile of POV messes up character counts with newlines. You can easily
convert the Unix file to a DOS/Windows file by saving it from POV-Ray. The
Codemax editor will convert it automatically.
Anyone know how to correct this?
-Nathan
Phil Clute <pcl### [at] tiacnet> wrote...
> The following is what I get when I run Jaime Vives Piqueres
> test04.pov & i_stsky.inc . The same stuff runs fine in official
> POV3.1g .
>
> <snip>
> Warning Stream to console.......On
> dfactor, // darkening factor
> border, // width of change zone
> fstart, // filter for lower layer
> fend // filter for upper layer
> )r <----ERROR
> <snip>
> \i_stsky.inc:32: error: object expected but undeclared identifier 'r'
> found instead.
>
> Does anyone else get this?
>
> The files are at Jaime's site in "CLOUDSCAPE" or I can send them
> to you if you don't already have them.
>
> --
> Phil
> ...coffee?...yes please! extra sugar,extra cream...Thank you.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>You can easily convert the Unix file to a DOS/Windows file by
>saving it from POV-Ray. The Codemax editor will convert it
>automatically.
Works now, thanks!
--
Phil
...coffee?...yes please! extra sugar,extra cream...Thank you.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
