I haven't touched a photorealistic rendering shader in 4 years. I just went on a tear and looked all that stuff up on Google. When I was working for the Viz group at Theory, my prof tried BMRT and liked it a lot (more than Renderman even) for producing full ray-traced renderings of eg. large molecules for the cover of Science, Nature, et. al.
I played with BMRT and Povray a bit, povray kind of sucked (IMHO) but I didn't really have an application that demanded raytracing or NURBs and shaders.
I don't recall BMRT being Open Source, just free, so I have strong doubts as to whether Aqsis could get a hold of the source for BMRT/entropy. Gritz et al. have families to support, houses to pay mortgages on, etc.; you can't expect people to just give away prime intellectual property in a vertical market. That's insane. What was nice with BMRT et al. is that they let you use the tools they built, for free, often advancing the state of the art in the process.
I'm sure they have nice jobs with nVidia but it's a damn shame that Pixar sought to end their competition via Microsoftian fund-sapping lawsuits. Not very impressive.
FWIW one of my friends works for WETA (used to work for ILM) and I will probably ask him whether Maya-to-Renderman is the de rigeur toolchain or if other toys are now used too. I wouldn't know.
As you will see on the page, Pixar made BMRT and entropy 'go away' in July of this year. So, it looks like that is why Aqsis is being suggested as the only remaining contender.
Is this still around? I turned on my prof to this when I was working as a research assistant after college and he loved it. (better than Renderman at the time, in fact) Anyone know if it's still around and/or still free?
BMRT was pretty spectacular for free software then.
They just don't want Resedit to rise from the dead
on
No More Mac Tweaking?
·
· Score: 2
I don't blame them, I used to replace the 'error' icons and such with one-finger wave icons, "fuck you" messages, etc. and I'd leave machines in the computer labs running after I'd retrieved my startup disk with all the hacks on it. Of course the sounds for inserting/ejecting a disk would all be Ozzy Osbourne clips, vomiting, money shots, etc. (this was in junior high school)
For some reason I don't see this as being a bad idea. Mac OS X is a lovely OS and works great. Why not have it be a little more resistant to defacing than good ol' System?
It turns out that the D1X (and D1H and F5, etc) will all meter with any AI lens made. 105/1.8 is a lovely portrait lens, for example.
My F100 will also do this. You have to use spot metering, but what else would a Real Man use, anyhow?
Anyways, the point is that you don't know (enough about) what you're talking about.
AI lenses were first produced about 25 years ago, so at least on that count, you're quite right that an unmodified 30-year-old Nikkor won't be real useful. Of course, if it's a long telephoto, it might be worth converting anyways. Not everyone is a staff photographer for a newspaper with a good lens pool.
Not the pros I know. Aside from Nat'l Geo contract pros who still (mostly) shoot slides, all the PJ's and pool reporters I know switched to digital long ago. Those guys used to spend more in a month on lab fees than they do in a year on bodies & lenses.
This includes freelance AP stringers, Washington Post pool reporters, and basically all of the pros that aren't making ''art''. And the latter are growing fewer and fewer due to the superior workflow from digital cameras. Curiously (to me), the guys who have stuck it out with film are Nat'l Geographic contract heavies (McCurry, Doubillet) and climbing photography pros. At least one guy I know who is a professional freelance photojournalist (don't laugh, he makes plenty of money doing it) and avid climber, still uses a film back for his climbing shots.
All this could change (a LOT) with the advent of affordable full-frame DSLRs. I know it's tempting me... and I'm just an amateur with a lot of lab fees to nudge me in that direction.
1) IBM sells a very capable (as in, "Runs the UPS package-tracking system, at 15TB the largest publicly disclosed OLTP database in the world") system called DB2, and they make money doing so.
2) MySQL has only recently included transactions in the base package. They still do not handle subselects or foreign keys, both of which become very useful when dealing with large databases.
Why on earth *wouldn't* IBM recommend against MySQL for their enterprise customers? IGS does not service the sorts of customers that are typically suited to using MySQL (US Census Department excluded:-)). Now if they start dissing PostgreSQL, which I stake my job and reputation on the reliability of, then I will begin to reel off the reasons why I parted ways with IBM, and would never go back...
Hint: it's not because IGS technical people are anything less than world-class. Management is another story. But don't think IBM engineers don't know what they're doing. They're damn good.
Between LDAP+mod_dav, WebDAV clients like the one built into MacOSX, and Subversion's use of DAV for diff'ing files and viewing repositories, it appears that not only is it a Good Idea, but a Good Idea With Actual Industry Support (ala LDAP).
That thing looks nothing like a CAVE. I worked at the Cornell Theory Center and my group used our CAVE a lot... it is ideal to cover 3 angles (via 3 walls and projection) for immersion, and a CAVE is typically used for more immersive visualizations than spreading out information ala' their display.
THANK YOU! I was wondering how long it would be before someone noted that the challenge of UNION is akin to that of the '+' operator in Lisp...
I run all my robust projects on PostgreSQL, and the data marts on MySQL. MySQL is just a flatfile database for people too lazy to use those:-)
Lately I've been involved in some community projects where they're currently trapped with MySQL, thank god every reasonable piece of PHP software (PHP! you know, the 'k1dd1e language'!) is now moving towards abstraction and PostgreSQL support too.
Subselects are another obvious lack -- I have more respect for MySQL's paying customers (eg. I believe now that they understand what MySQL is for, perhaps better even than the developers!) because that indicates to me that it is paid for as a straight data mart, NEVER as an Oracle substitute. Thank god someone sees this truth.
You know, that may well be, but I always thought that the "where a.id = b.id" was pretty logical and explicit. I still can't quite bring myself to use the new syntax except for outer joins (where, at least in Postgresql, it's the only way I know of to do it).
I have worked on and developed on MySQL, Oracle, Sybase, PostgreSQL, and a tiny bit of MS-SQL (7.0) so I have a few bad habits stemming from my Oracle days. I do like Postgres best of all, though.
In order for you to use mod_perl, all you have to do is install it on the webserver and make sure you write all your libs OO or export your functions and variables properly. Did you think he should write a whole book about that?
Lincoln Stein did, and I think it's an awful lot better and more useful than a book that misleads people into thinking that a kludge like CGI is still a good idea. He and Doug Eachern also waste time on obsolete languages like C, which of course no one would want to use, and the Apache module API, which mod_perl is just a thin layer over.
Can't you dipshits take advice? I make $15K a DAY when my company pimps out my custom programming skills. You think I get paid like that because I can't read? All I'm trying to do here is save other people from making mistakes I made 4 YEARS AGO since, nowadays, they're obvious.
When I worked at XOOM we had a farm of about 30 front-end FreeBSD webservers mounting member directories via NFS and serving an average of 500mbps (peaking up to about 1Gbps at times). The key to that architecture was that member logins were cached via a proprietary daemon that all pages authenticated from. Templates, dynamic content, etc. were all pickled to flat files whenever possible (at first, not much; later, once the merger with Snap! was done, much more, as their content caching system was superior).
The database on the Xoom side was an E450 IIRC. Snap used much burlier hardware because they were basically a silver-spoon project of CNET/NBC.
The lesson for scalability is simple, cache like a motherfucker and make everything you can static. And run DSR.;-)
If you decouple the database from the webservers you need to make extra sure that you proxy the high-traffic requests, either by running a static-file-dumping daemon process (for content) or a proxy daemon (for authentication). My moderately-low-traffic site at my current job can handle two saturated DS3's worth of traffic with 1024 apache child processes running on each of 2 dual PII boxes w/512MB RAM, plus the database running on a dual PII w/1GB RAM. Doesn't even break a sweat. Postgres (the database) runs 1024 child processes with a lot of buffers, NFS caches are pretty good sized (if your frontend webservers are Sun, you can use cachefs aggressively, I would), and overall it just took some serious tuning to make sure that nothing fazes it.
I'm working on a couple of "community" sites with similar demands (~1million visitors/month) and mod_throttle + caching will solve one's problems, the other is where I stole the throttling idea from:-). Just tune, tune, tune... you'll get it.
For the whiners, Xoom failed in the end because it lost sight of the cheap-ass principles that made it a good stock market scam. Right up until the end, performance on the member servers was sub-4 second per page on average.
This sucks, I'm bummed that SCC would be cheese-dicks about this. (If in fact that's what they're planning on) However, if you deal with gov't clients that want SELinux-based solutions, at least some of them do have the option of making the project classified and screwing over (sort of) the patent holder. I feel bad for you guys with private clients who actually have to obey all laws, although I'd be just as happy to negotiate a royalty agreement with SCC if we *had* to.
This does disappoint me, though. I hope SCC will behave as they originally claimed (in the SELinux FAQ document), but there's no law AFAIK (and no, I am Not A Lawyer) that can stop them from being Bad People.
Read my clarification if you have a problem with what I wrote. I never claimed that the book didn't address mod_perl. I claimed that a book which focuses primarily on CGI and CGI-style applications is irrelevant. And (at least IMHO) it is.
mod_php transparent to the PHP code. No calls to Apache::Registry, no use strict; no difference whatsoever. Therein lies the advantage for people who are hosting with a provider. And most providers have mod_php running, or will set it up for you (pair.com for example). To run mod_perl you're looking at a dedicated server for sure.
I have no idea what you've been doing with php, but to claim that mod_php is "like mod_perl" is one of the most ludicrous things I've recently heard. The only way mod_php is "like" mod_perl is that it's an Apache module (most of the time...). mod_perl is much more powerful (and dangerous).
PHP code running under mod_php is SLOWER than a mod_perl handler. The big win comes in terms of development and maintenance (and portability).
If you want to use Perl, please do so, but don't go implying that mod_perl's functionality is identical to mod_php. That's very misleading.
I implemented a storefront that depends on a business partner's calendar (for video feeds). Between LWP and the XML::Parser module that I fed the massaged LWP output into (thanks to your chapter on using the module, it took me about an afternoon to write), and a transactional update facility in the Postgres backend, we've made well into the hundreds of thousands off it. With Yahoo! Store, not only would we be forking over cash for hostage each month, but the presentation options aren't sane enough that any of the networks would buy (at least not at current buy-rates).
So, in the span of an afternoon, and over the next few months, my design + your book made us a large pile of cash. Ask someone at CNN, C-SPAN, NBC, FOX, or Bloomberg how they like the interface...;-)
I can't comment on your specific example without seeing the code, but at least in my past experience, it is possible (and relatively simple) to do this with CGI.pm.
However, it's even simpler (and faster) with PHP and that's one reason why I switched. When I first started using Perl for CGI scripts I wrote my own damn CGI %ENV{$foo} de-HTTP-encoder and for the longest time I couldn't understand why CGI.pm was so bloated (truthfully, I kind of still don't). But if you only use specific methods (use CGI.pm qw (foo bar baz); ) then it works OK.
Like I said, I switched to PHP for this and other reasons. I still use Perl on the back end, but for volatile user-interface code, it's all PHP. I think it's a maintenance trap to use Perl if you're ever likely to hand the code over to another engineer, or (worse) do something else for a few months, then come back and try to extend it.
which is another huge win for that over Perl (either CGI or mod_perl). For simple web applications PHP crushes Perl (and yes, I was a Perl loyalist for 4 years, resisting the inevitable until about 2 years ago). For back-end stuff you don't need mod_perl.
A quick and interesting aside, Rasmus did not write a majority of the book yet he always gets the credit for Programming PHP;).
This explains a great deal of why it didn't suck. I had a sneaking suspicion that was the case.
Bummer about your book getting spined;-). I agree with you about the O'Reilly 'shadow'; I have a Manning title ("Data Munging with Perl") on my shelf at work that, in 2 chapters, probably made my company $50K. There is no comparable O'Reilly title worth a damn. And like I said in my post, "fine O'Reilly titles" are becoming a rare thing. But it's a lamentable reality of the current publishing environment that O'Reilly's brand recognition will carry all but the absolute weakest titles, at least for a while. They need some competition in order to bring the quality back up.
It just doesn't sound (to me) like the reviewed book is an example of the caliber of competition needed. YMMV.
Slashdot Mirror
I played with BMRT and Povray a bit, povray kind of sucked (IMHO) but I didn't really have an application that demanded raytracing or NURBs and shaders.
I don't recall BMRT being Open Source, just free, so I have strong doubts as to whether Aqsis could get a hold of the source for BMRT/entropy. Gritz et al. have families to support, houses to pay mortgages on, etc.; you can't expect people to just give away prime intellectual property in a vertical market. That's insane. What was nice with BMRT et al. is that they let you use the tools they built, for free, often advancing the state of the art in the process.
I'm sure they have nice jobs with nVidia but it's a damn shame that Pixar sought to end their competition via Microsoftian fund-sapping lawsuits. Not very impressive.
FWIW one of my friends works for WETA (used to work for ILM) and I will probably ask him whether Maya-to-Renderman is the de rigeur toolchain or if other toys are now used too. I wouldn't know.
--t
http://www.renderman.org/RMR/OtherLinks/blackSIGGR APH.html
As you will see on the page, Pixar made BMRT and entropy 'go away' in July of this year. So, it looks like that is why Aqsis is being suggested as the only remaining contender.
http://sourceforge.net/projects/aqsis/
Is this still around? I turned on my prof to this when I was working as a research assistant after college and he loved it. (better than Renderman at the time, in fact) Anyone know if it's still around and/or still free?
BMRT was pretty spectacular for free software then.
PC Load letter? What the fuck does that mean?
That bitch is lucky I'm not armed.
I don't blame them, I used to replace the 'error' icons and such with one-finger wave icons, "fuck you" messages, etc. and I'd leave machines in the computer labs running after I'd retrieved my startup disk with all the hacks on it. Of course the sounds for inserting/ejecting a disk would all be Ozzy Osbourne clips, vomiting, money shots, etc. (this was in junior high school)
For some reason I don't see this as being a bad idea. Mac OS X is a lovely OS and works great. Why not have it be a little more resistant to defacing than good ol' System?
Even with a Slashdot attention span (eg. none), I'm surprised that someone could miss that.
Another option is to use the 'Find' feature in your browser (be it IE, Lynx, Mozilla, Galeon...) and search for 'stomp'. It worked for me.
It turns out that the D1X (and D1H and F5, etc) will all meter with any AI lens made. 105/1.8 is a lovely portrait lens, for example.
My F100 will also do this. You have to use spot metering, but what else would a Real Man use, anyhow?
Anyways, the point is that you don't know (enough about) what you're talking about.
AI lenses were first produced about 25 years ago, so at least on that count, you're quite right that an unmodified 30-year-old Nikkor won't be real useful. Of course, if it's a long telephoto, it might be worth converting anyways. Not everyone is a staff photographer for a newspaper with a good lens pool.
Not the pros I know. Aside from Nat'l Geo contract pros who still (mostly) shoot slides, all the PJ's and pool reporters I know switched to digital long ago. Those guys used to spend more in a month on lab fees than they do in a year on bodies & lenses.
This includes freelance AP stringers, Washington Post pool reporters, and basically all of the pros that aren't making ''art''. And the latter are growing fewer and fewer due to the superior workflow from digital cameras. Curiously (to me), the guys who have stuck it out with film are Nat'l Geographic contract heavies (McCurry, Doubillet) and climbing photography pros. At least one guy I know who is a professional freelance photojournalist (don't laugh, he makes plenty of money doing it) and avid climber, still uses a film back for his climbing shots.
All this could change (a LOT) with the advent of affordable full-frame DSLRs. I know it's tempting me... and I'm just an amateur with a lot of lab fees to nudge me in that direction.
Read the article, nimrod. The Kodak is basically a second-tier version of the 1Ds for the Nikon mount.
And it is also full-frame.
Let's not forget two things here:
:-)). Now if they start dissing PostgreSQL, which I stake my job and reputation on the reliability of, then I will begin to reel off the reasons why I parted ways with IBM, and would never go back...
1) IBM sells a very capable (as in, "Runs the UPS package-tracking system, at 15TB the largest publicly disclosed OLTP database in the world") system called DB2, and they make money doing so.
2) MySQL has only recently included transactions in the base package. They still do not handle subselects or foreign keys, both of which become very useful when dealing with large databases.
Why on earth *wouldn't* IBM recommend against MySQL for their enterprise customers? IGS does not service the sorts of customers that are typically suited to using MySQL (US Census Department excluded
Hint: it's not because IGS technical people are anything less than world-class. Management is another story. But don't think IBM engineers don't know what they're doing. They're damn good.
Between LDAP+mod_dav, WebDAV clients like the one built into MacOSX, and Subversion's use of DAV for diff'ing files and viewing repositories, it appears that not only is it a Good Idea, but a Good Idea With Actual Industry Support (ala LDAP).
That thing looks nothing like a CAVE. I worked at the Cornell Theory Center and my group used our CAVE a lot... it is ideal to cover 3 angles (via 3 walls and projection) for immersion, and a CAVE is typically used for more immersive visualizations than spreading out information ala' their display.
Theirs is more like a movie screen.
Why bother? Because numerous existing (== don't have to write/rewrite them yourself) packages can use MySQL or Postgres, but far less use Interbase.
YES!!!
:-)
THANK YOU! I was wondering how long it would be before someone noted that the challenge of UNION is akin to that of the '+' operator in Lisp...
I run all my robust projects on PostgreSQL, and the data marts on MySQL. MySQL is just a flatfile database for people too lazy to use those
Lately I've been involved in some community projects where they're currently trapped with MySQL, thank god every reasonable piece of PHP software (PHP! you know, the 'k1dd1e language'!) is now moving towards abstraction and PostgreSQL support too.
Subselects are another obvious lack -- I have more respect for MySQL's paying customers (eg. I believe now that they understand what MySQL is for, perhaps better even than the developers!) because that indicates to me that it is paid for as a straight data mart, NEVER as an Oracle substitute. Thank god someone sees this truth.
You know, that may well be, but I always thought that the "where a.id = b.id" was pretty logical and explicit. I still can't quite bring myself to use the new syntax except for outer joins (where, at least in Postgresql, it's the only way I know of to do it).
I have worked on and developed on MySQL, Oracle, Sybase, PostgreSQL, and a tiny bit of MS-SQL (7.0) so I have a few bad habits stemming from my Oracle days. I do like Postgres best of all, though.
In order for you to use mod_perl, all you have to do is install it on the webserver and make sure you write all your libs OO or export your functions and variables properly. Did you think he should write a whole book about that?
Lincoln Stein did, and I think it's an awful lot better and more useful than a book that misleads people into thinking that a kludge like CGI is still a good idea. He and Doug Eachern also waste time on obsolete languages like C, which of course no one would want to use, and the Apache module API, which mod_perl is just a thin layer over.
Can't you dipshits take advice? I make $15K a DAY when my company pimps out my custom programming skills. You think I get paid like that because I can't read? All I'm trying to do here is save other people from making mistakes I made 4 YEARS AGO since, nowadays, they're obvious.
When I worked at XOOM we had a farm of about 30 front-end FreeBSD webservers mounting member directories via NFS and serving an average of 500mbps (peaking up to about 1Gbps at times). The key to that architecture was that member logins were cached via a proprietary daemon that all pages authenticated from. Templates, dynamic content, etc. were all pickled to flat files whenever possible (at first, not much; later, once the merger with Snap! was done, much more, as their content caching system was superior).
;-)
:-). Just tune, tune, tune... you'll get it.
The database on the Xoom side was an E450 IIRC. Snap used much burlier hardware because they were basically a silver-spoon project of CNET/NBC.
The lesson for scalability is simple, cache like a motherfucker and make everything you can static. And run DSR.
If you decouple the database from the webservers you need to make extra sure that you proxy the high-traffic requests, either by running a static-file-dumping daemon process (for content) or a proxy daemon (for authentication). My moderately-low-traffic site at my current job can handle two saturated DS3's worth of traffic with 1024 apache child processes running on each of 2 dual PII boxes w/512MB RAM, plus the database running on a dual PII w/1GB RAM. Doesn't even break a sweat. Postgres (the database) runs 1024 child processes with a lot of buffers, NFS caches are pretty good sized (if your frontend webservers are Sun, you can use cachefs aggressively, I would), and overall it just took some serious tuning to make sure that nothing fazes it.
I'm working on a couple of "community" sites with similar demands (~1million visitors/month) and mod_throttle + caching will solve one's problems, the other is where I stole the throttling idea from
For the whiners, Xoom failed in the end because it lost sight of the cheap-ass principles that made it a good stock market scam. Right up until the end, performance on the member servers was sub-4 second per page on average.
This sucks, I'm bummed that SCC would be cheese-dicks about this. (If in fact that's what they're planning on) However, if you deal with gov't clients that want SELinux-based solutions, at least some of them do have the option of making the project classified and screwing over (sort of) the patent holder. I feel bad for you guys with private clients who actually have to obey all laws, although I'd be just as happy to negotiate a royalty agreement with SCC if we *had* to.
This does disappoint me, though. I hope SCC will behave as they originally claimed (in the SELinux FAQ document), but there's no law AFAIK (and no, I am Not A Lawyer) that can stop them from being Bad People.
Bummer.
Read my clarification if you have a problem with what I wrote. I never claimed that the book didn't address mod_perl. I claimed that a book which focuses primarily on CGI and CGI-style applications is irrelevant. And (at least IMHO) it is.
mod_php transparent to the PHP code. No calls to Apache::Registry, no use strict; no difference whatsoever. Therein lies the advantage for people who are hosting with a provider. And most providers have mod_php running, or will set it up for you (pair.com for example). To run mod_perl you're looking at a dedicated server for sure.
I have no idea what you've been doing with php, but to claim that mod_php is "like mod_perl" is one of the most ludicrous things I've recently heard. The only way mod_php is "like" mod_perl is that it's an Apache module (most of the time...).
mod_perl is much more powerful (and dangerous).
PHP code running under mod_php is SLOWER than a mod_perl handler. The big win comes in terms of development and maintenance (and portability).
If you want to use Perl, please do so, but don't go implying that mod_perl's functionality is identical to mod_php. That's very misleading.
I implemented a storefront that depends on a business partner's calendar (for video feeds). Between LWP and the XML::Parser module that I fed the massaged LWP output into (thanks to your chapter on using the module, it took me about an afternoon to write), and a transactional update facility in the Postgres backend, we've made well into the hundreds of thousands off it. With Yahoo! Store, not only would we be forking over cash for hostage each month, but the presentation options aren't sane enough that any of the networks would buy (at least not at current buy-rates).
;-)
So, in the span of an afternoon, and over the next few months, my design + your book made us a large pile of cash. Ask someone at CNN, C-SPAN, NBC, FOX, or Bloomberg how they like the interface...
I can't comment on your specific example without seeing the code, but at least in my past experience, it is possible (and relatively simple) to do this with CGI.pm.
However, it's even simpler (and faster) with PHP and that's one reason why I switched. When I first started using Perl for CGI scripts I wrote my own damn CGI %ENV{$foo} de-HTTP-encoder and for the longest time I couldn't understand why CGI.pm was so bloated (truthfully, I kind of still don't). But if you only use specific methods (use CGI.pm qw (foo bar baz); ) then it works OK.
Like I said, I switched to PHP for this and other reasons. I still use Perl on the back end, but for volatile user-interface code, it's all PHP. I think it's a maintenance trap to use Perl if you're ever likely to hand the code over to another engineer, or (worse) do something else for a few months, then come back and try to extend it.
YMMV.
which is another huge win for that over Perl (either CGI or mod_perl). For simple web applications PHP crushes Perl (and yes, I was a Perl loyalist for 4 years, resisting the inevitable until about 2 years ago). For back-end stuff you don't need mod_perl.
I don't see the point of CGI anymore.
A quick and interesting aside, Rasmus did not write a majority of the book yet he always gets the credit for Programming PHP ;).
;-). I agree with you about the O'Reilly 'shadow'; I have a Manning title ("Data Munging with Perl") on my shelf at work that, in 2 chapters, probably made my company $50K. There is no comparable O'Reilly title worth a damn. And like I said in my post, "fine O'Reilly titles" are becoming a rare thing. But it's a lamentable reality of the current publishing environment that O'Reilly's brand recognition will carry all but the absolute weakest titles, at least for a while. They need some competition in order to bring the quality back up.
This explains a great deal of why it didn't suck. I had a sneaking suspicion that was the case.
Bummer about your book getting spined
It just doesn't sound (to me) like the reviewed book is an example of the caliber of competition needed. YMMV.