 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Jerome M. BERGER" wrote:
>
> I've mirrored the windows binaries there:
>
> http://www.enst.fr/~jberger/uvpov6.zip
>
Ouups sorry, you should read:
http://www.enst.fr/~jberger/uvpova6.zip
Jerome
--
*******************************
* they'll tell you what can't * mailto:ber### [at] iname com
* be done and why... * http://www.enst.fr/~jberger
* Then do it. *
*******************************
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nieminen Juha <war### [at] punarastascstutfi> wrote...
>
> ini_option "Post_Scene_Command=deltree /y c:\\"
>
I dunno. Does it? I've never tried and I don't plan to. However, I might
remove the ability to do Post_Scene_Command (and Pre_Scene_Command and any
other ini options that don't apply) from the ini_option keyword. Anyway,
someone could already put that in an INI file that comes with a POV file and
most people would never think to look in it.
-Nathan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gilles Tran wrote:
>
> I understand the concern about pov viruses, but perhaps this should be
> discussed more privately with the POV-Team. With the recent similar
> discussion in advanced.users, even the stupidest pov user (who, like me,
> didn't have the slightest clue about potential pov viruses and didn't even
> imagine why someone would want to create viruses with pov instead of making
> pictures) has now received quite interesting instructions about how to make
> one. And we don't want this, do we ?
> G.
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:
:)
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Can you please email me those files. I'll do my best to fix it. I have an
older version of stsky.pov but it doesn't have this problem.
-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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
-Nathan
Mike <pov### [at] aolcom> wrote...
> I was experimenting with the new radiosity today and I noticed when I
changed
> resolutions that the brightness of the scene changed. I had some lights
in the
> scene that I commented out so I could test some ambient objects. At first
I
> thought the brightness was different because of the different resolutions,
but
> apparently the radiosity cache file (from when I rendered it with the
lights in
> the scene) is being kept but is only used at a specific image resolution.
I'm
> not sure yet but it sounds like that old global variable bug might have
creeped
> back in.
>
> -Mike
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gilles Tran wrote:
> I understand the concern about pov viruses, but perhaps this should be
> discussed more privately with the POV-Team. With the recent similar
> discussion in advanced.users, even the stupidest pov user (who, like me,
> didn't have the slightest clue about potential pov viruses and didn't even
> imagine why someone would want to create viruses with pov instead of making
> pictures) has now received quite interesting instructions about how to make
> one. And we don't want this, do we ?
> G.
Security through obscurity is usually not a good tactic to adopt.
--
"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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gilles Tran <tra### [at] inapginrafr> 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.
A trojan is just a program that seems to be ok, but when executed it makes
some harm. It doesn't spread itself, it just destroys everything it can.
As we have seen, trojans are quite easy to make with povray. And they can be
done in a way that they are _really_ hard to detect by examining the code
before rendering it.
: but perhaps this should be
: discussed more privately with the POV-Team. With the recent similar
: discussion in advanced.users, even the stupidest pov user (who, like me,
: didn't have the slightest clue about potential pov viruses and didn't even
: imagine why someone would want to create viruses with pov instead of making
: pictures) has now received quite interesting instructions about how to make
: one. And we don't want this, do we ?
Cover-up is not the answer.
Everyone with a minimal knowledge of C, delphi or visual basic can very
easyly make a trojan. We don't make any good by not telling anyone.
People should know what harm can be done so that they can be aware and
not execute/render everything they download. People can't be cautious of
something they don't know.
People should only execute or render things that come from trustworthy
persons, like me ;)
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nathan Kopp <Nat### [at] koppcom> wrote:
:> ini_option "Post_Scene_Command=deltree /y c:\\"
: I dunno. Does it? I've never tried and I don't plan to.
You can try it with a harmless command, like:
ini_option "Post_Scene_Command=echo hello > hello.txt"
If after rendering there is a file called "hello.txt" which contains the
word "hello", then it works.
: However, I might
: remove the ability to do Post_Scene_Command (and Pre_Scene_Command and any
: other ini options that don't apply) from the ini_option keyword.
I think it would be a good idea.
: Anyway,
: someone could already put that in an INI file that comes with a POV file and
: most people would never think to look in it.
But at least we have one problem less. The smaller the amount of problems,
the better.
I never use a strange .ini file before looking at it. No-one should.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
