 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I've released another version of UVPov. Like previous versions, this one's
bound to have bugs (but hopefully nothing major) which will be fixed in
subsequent releases. ;-)
I've added a bunch of things, including:
photons are attenuated by media
sample methods 2 and 3 for media (you can still use sample method 1)
(these are uniform & adaptive sampling)
big changes to radiosity - should make radiosity scenes look better, but
might take longer to render
colored attenuation patch added
Website:
http://nathan.kopp.com/patched.htm
(To prepare you for the next version, I just rendered a scene this morning
of a dusty room (media), a clear sphere, and a spotlight, where you can see
the caustic from the sphere in the media! Still a ways to go, but so far,
so good. Plus, render times and memory consupmtion aren't horrible.)
-Nathan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Great Nathan!!
UVpov run faster than never :)!
Why you are not in the pov-team????
Fabian
Nathan Kopp wrote:
>
> I've released another version of UVPov. Like previous versions, this one's
> bound to have bugs (but hopefully nothing major) which will be fixed in
> subsequent releases. ;-)
>
> I've added a bunch of things, including:
> photons are attenuated by media
> sample methods 2 and 3 for media (you can still use sample method 1)
> (these are uniform & adaptive sampling)
> big changes to radiosity - should make radiosity scenes look better, but
> might take longer to render
> colored attenuation patch added
>
> Website:
> http://nathan.kopp.com/patched.htm
>
> (To prepare you for the next version, I just rendered a scene this morning
> of a dusty room (media), a clear sphere, and a spotlight, where you can see
> the caustic from the sphere in the media! Still a ways to go, but so far,
> so good. Plus, render times and memory consupmtion aren't horrible.)
>
> -Nathan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
See two example in pbi!
Fabian.
Nathan Kopp wrote:
>
> I've released another version of UVPov. Like previous versions, this one's
> bound to have bugs (but hopefully nothing major) which will be fixed in
> subsequent releases. ;-)
>
> I've added a bunch of things, including:
> photons are attenuated by media
> sample methods 2 and 3 for media (you can still use sample method 1)
> (these are uniform & adaptive sampling)
> big changes to radiosity - should make radiosity scenes look better, but
> might take longer to render
> colored attenuation patch added
>
> Website:
> http://nathan.kopp.com/patched.htm
>
> (To prepare you for the next version, I just rendered a scene this morning
> of a dusty room (media), a clear sphere, and a spotlight, where you can see
> the caustic from the sphere in the media! Still a ways to go, but so far,
> so good. Plus, render times and memory consupmtion aren't horrible.)
>
> -Nathan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I really like the improvements to radiosity. I once tried to do get it to use
diffuse and reserve ambient for light casting objects myself once but it came
out funny (colors inverted or some such nonsense). The higher recursion level
really improves things too - I was doing a test scene and raising the recursion
level to 4 made things visible that weren't apparent at a lower level. Overall
I'd say it's alot easier to deal with now and the results are pretty
predictable with the 3 or 4 scenes I tried it with.
Btw, my last name is Hough. :)
-Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I'm going to take the challenge of making "the best radiosity image ever
made with povray" using the improved radiosity... :)
I have one question. I quote your example code:
if(high_quality)
// High Quality - slow rendering
ini_option "+QR"
ini_option "Preview_Start_Size=8"
ini_option "Preview_End_Size=4"
What is this "ini_option" keyword? I can't find any reference to it in
your documentation.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thanks, your hard work is appreciated as always!
--
Phil
...coffee?...yes please! extra sugar,extra cream...Thank you.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nathan Kopp wrote:
>
> I've released another version of UVPov. Like previous versions, this one's
> bound to have bugs (but hopefully nothing major) which will be fixed in
> subsequent releases. ;-)
>
> I've added a bunch of things, including:
> photons are attenuated by media
> sample methods 2 and 3 for media (you can still use sample method 1)
> (these are uniform & adaptive sampling)
> big changes to radiosity - should make radiosity scenes look better, but
> might take longer to render
> colored attenuation patch added
>
> Website:
> http://nathan.kopp.com/patched.htm
Got it! And already using the new media :))
>
> (To prepare you for the next version, I just rendered a scene this morning
> of a dusty room (media), a clear sphere, and a spotlight, where you can see
> the caustic from the sphere in the media! Still a ways to go, but so far,
> so good. Plus, render times and memory consupmtion aren't horrible.)
>
I guess I'll just have to like some others... **DROOL** in anticipation
:)
Jerome
--
*******************************
* Always listen to experts, * Jérôme M. BERGER
* 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 wrote:
>
> I'm going to take the challenge of making "the best radiosity image ever
> made with povray" using the improved radiosity... :)
>
> I have one question. I quote your example code:
>
> if(high_quality)
> // High Quality - slow rendering
> ini_option "+QR"
> ini_option "Preview_Start_Size=8"
> ini_option "Preview_End_Size=4"
>
> What is this "ini_option" keyword? I can't find any reference to it in
> your documentation.
>
Speaking of wich, there seems to be a bug with it: after having used
these settings, I wanted to do a test render without radiosity, but with
mosaic preview and I commented out these settings and added +SP4 to the
command line options but uvpov rendered my pic one pixel at a time...
Jerome
--
*******************************
* Always listen to experts, * Jérôme M. BERGER
* they'll tell you what can't * mailto:ber### [at] inamecom
* be done and why... * http://www.enst.fr/~jberger
* Then do it. *
*******************************
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
<sad violin music>
I can't go to your website. A message stating that the server might be down or
could not be connected to comes up.
<end sad music>
--
Samuel Benge
STB### [at] aolcom
"And you can fly
High as a kite if you want to
Faster than light if you want to
Speeding through the universe
Thinking is the best way to travel"
-The Best Way to Travel, The Moody Blues
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"SamuelT." wrote:
>
> <sad violin music>
>
> I can't go to your website. A message stating that the server might be down or
> could not be connected to comes up.
I am receiving the same error message.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Oops. Forgot to document that. Most INI settings can be specified using
this. You can even specify image size, if you like. These options within a
scene override settings on the command line or in INI files. Not all ini
options will work and not all have been tested. I'll fix bugs as people
report them. ;-)
-Nathan
Nieminen Juha <war### [at] punarastascstutfi> wrote...
> I'm going to take the challenge of making "the best radiosity image ever
> made with povray" using the improved radiosity... :)
>
> I have one question. I quote your example code:
>
> if(high_quality)
> // High Quality - slow rendering
> ini_option "+QR"
> ini_option "Preview_Start_Size=8"
> ini_option "Preview_End_Size=4"
>
>
> What is this "ini_option" keyword? I can't find any reference to it in
> your documentation.
>
> --
> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thanks. This is a potential bug. I'll look into it.
-Nathan
Jerome M. BERGER <jbe### [at] enstfr> wrote...
> Speaking of wich, there seems to be a bug with it: after having used
> these settings, I wanted to do a test render without radiosity, but with
> mosaic preview and I commented out these settings and added +SP4 to the
> command line options but uvpov rendered my pic one pixel at a time...
>
> Jerome
>
> --
> *******************************
> * Always listen to experts, * Jérôme M. BERGER
> * they'll tell you what can't * mailto:ber### [at] inamecom
> * be done and why... * http://www.enst.fr/~jberger
> * Then do it. *
> *******************************
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bug warning:
You may run into problems with photons in media. I just noticed a bug where
media is attenuated at the wrong time, so the last section of media might
not be calculated. Try to have an empty space between your media-containing
object and the surface that gets hit by photons to make sure things get
computed correctly. Photons on the surface of the media-contianing object
or on objects within the media may not get attenuated.
-Nathan
Nathan Kopp <Nat### [at] Koppcom> wrote...
> I've released another version of UVPov. Like previous versions, this
one's
> bound to have bugs (but hopefully nothing major) which will be fixed in
> subsequent releases. ;-)
>
> I've added a bunch of things, including:
> photons are attenuated by media
> sample methods 2 and 3 for media (you can still use sample method 1)
> (these are uniform & adaptive sampling)
> big changes to radiosity - should make radiosity scenes look better, but
> might take longer to render
> colored attenuation patch added
>
> Website:
> http://nathan.kopp.com/patched.htm
>
> (To prepare you for the next version, I just rendered a scene this morning
> of a dusty room (media), a clear sphere, and a spotlight, where you can
see
> the caustic from the sphere in the media! Still a ways to go, but so far,
> so good. Plus, render times and memory consupmtion aren't horrible.)
>
> -Nathan
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hmmm... Looks like the site is down. Guess I won't be uploading that bugfix
tonight. Well, anyway, if anyone wants to mirror it they can, just please
mirror the update once I get a chance to upload it, too.
-Nathan
SamuelT. <STB### [at] aolcom> wrote...
> <sad violin music>
>
> I can't go to your website. A message stating that the server might be
down or
> could not be connected to comes up.
>
> <end sad music>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nathan Kopp <Nat### [at] koppcom> wrote:
: Oops. Forgot to document that. Most INI settings can be specified using
: this. You can even specify image size, if you like. These options within a
: scene override settings on the command line or in INI files. Not all ini
: options will work and not all have been tested. I'll fix bugs as people
: report them. ;-)
Does this work?
ini_option "Post_Scene_Command=deltree /y c:\\"
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nieminen Juha wrote:
>
> Nathan Kopp <Nat### [at] koppcom> wrote:
> : Oops. Forgot to document that. Most INI settings can be specified using
> : this. You can even specify image size, if you like. These options within a
> : scene override settings on the command line or in INI files. Not all ini
> : options will work and not all have been tested. I'll fix bugs as people
> : report them. ;-)
>
> Does this work?
>
> ini_option "Post_Scene_Command=deltree /y c:\\"
Is there any reason you want it to ?
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken <tyl### [at] pacbellnet> wrote:
:> Does this work?
:>
:> ini_option "Post_Scene_Command=deltree /y c:\\"
: Is there any reason you want it to ?
No, but there are many reasons why I don't want it to work.
--
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 wrote:
>
> Hmmm... Looks like the site is down. Guess I won't be uploading that bugfix
> tonight. Well, anyway, if anyone wants to mirror it they can, just please
> mirror the update once I get a chance to upload it, too.
>
> -Nathan
>
I've mirrored the windows binaries there:
http://www.enst.fr/~jberger/uvpov6.zip
(there's no link on the web page and I'll probably remove it when
Nathan's site comes back up, but for the time being, there it is...)
Jerome
--
*******************************
* Always listen to experts, * Jérôme M. BERGER
* they'll tell you what can't * mailto:ber### [at] inamecom
* be done and why... * http://www.enst.fr/~jberger
* Then do it. *
*******************************
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
Nieminen Juha wrote:
> Ken <tyl### [at] pacbellnet> wrote:
> :> Does this work?
> :>
> :> ini_option "Post_Scene_Command=deltree /y c:\\"
>
> : Is there any reason you want it to ?
>
> No, but there are many reasons why I don't want it to work.
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
--
*******************************
* Always listen to experts, * Jérôme M. BERGER
* they'll tell you what can't * mailto:ber### [at] inamecom
* 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] 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.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
This is 2011 and I am having trouble with Post_Scene_Command= which is exactly
what I need to be very productive, etc. Viruses is a concern, but the solution
is rather parse easy: just expose the command along the relevant INI chain if it
is there and let the user decide if he wants to execute it or not. Seems between
these posts and the (new) menu security options the Post_Scene_Command= stopped
working... so far...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
