The export script for Virtualight does not seem to run under Publisher 225
Ack! Haven't had a chance to test it yet, but it might be because the python API has changed in various ways. I'll look into it later on.
This leads to another interesting question, though: Who's up for some really good support for external renderers? I mean native, hardcoded, compiled c-style export functions...
|This leads to another interesting question, though: Who's up for some really good support for external renderers? I mean native, hardcoded, compiled c-style export functions... |
ME! ME!! ME!!!
That is what open source is all about
Well, I really like VirtuaLight, and I'm very comfortable with the VIB- and VS languages. Currently I'm coding a shader editor for VS in Java. But I'm not too hot on C-programming though - I've done it before, but it was a long time ago, so most of my skills in that area are pretty useless...
But I picture this: In the render buttons, a drop-down box in which I can select between the Blender default renderer, the unified renderer, LightFlow or VirtuaLight (and more soon enough). Make the selection, press F12 and voila! For LF and VL-renders the code would handle converting the internal Blender scene data and pass it to LightFlow or VirtuaLight. Unfortunately we would have to build some modules to provide the proper material editing from within Blender as well. And some option to add special attributes to lightsources etc, since there are more things to consider on top of the standard Blender settings.
And some module for setting up render specific global settings, such as irradiance, caustics and more.
What we REALLY need is a general purpose plug-in architecture that could allow anyone to code support for any external renderer. Something like the 'render effects' in 3DSMAX, which allow passing data in an orderly fashion to any app capable of handling some form of image rendering. Sooner or later someone will want to convert their anim to .swf as well...
Lightflow, for now, is dead.
VL is great if your a Micro$oft abuser, what about the rest of us
IMHO, Povray is available for the majority of OS's and I believe is the best candidate: Windows, Mac OS/Mac OS X, i86 Linux and IRIX from the SGI's freeware website or CD's.
I guess what I'm wondering is why everyone talks about a plug in architecture?
Having the ability to code python scripts is the most powerful "plug in" of all, and given a STABLE API of python, (one which changes by gaining functionality, but doesn't break old functions), it would continue to be very useful.
After all, a plugin writer usually would need to know a programming language in the first place - python is one of the easiest languages to learn for anyone, in my opinion, and it is an extermely powerful language, more powerful than just crappy plain C or Perl or languages like that. You would still have the API, the "blender plug - in interface" for the python code. Even now that exists. All people would need to do is add more functionality to that API.
To be honest, I think some use the words "plugins" as a buzzword. It just sounds cool.
Most people don't realize how awesome python really is until they dig in and taste some of it. It even forces code style on you - formatting is part of the code. Python is very clean.
The biggest benefit is the python isn't compiled, and it will run on all blender systems. One file, multiple users. HMM. .NET in its own form eh?
why would you want to use a raytracer?
3. global illumination
4. classic interior radiosity
6. license (yes it does matter)
Lets see how they stack up:
OK means no complaints
3. Seems to have artifacts and is tremedously slow...
5. Bad. Win32 only. Does it run in wine? give it a shot...
6. Worse than Beer. non commercial use onlt\y
Renderman-Compatibles (BMRT does not count)
1. None (except 3delight expensive PRman)
2. None (ex 3delight & PRman)
3. None (ex PRman)
4. None (ex PRman)
5. runs all over
6. it's got a standard, we can integrate it, but what's free and good? the only OSS ones i could find are inferior to blender's scanliner.
2. OK - really quite nice in fact
3. Nice, but still artifact-prone, and slow
5. Linux x86 and Win32 only
6. non-commercial use only. poop.
no development in almost 3 years.
integratable as of now? no
3. Pretty primitive and slow. think multi-day rendertimes
4. worse than blender's
5. win32, linux, others i assume,
6. OSS, not sure what though...
integratable? yes, but i would hope not. I don't like it's style...
3. There, but far too slow at this point. eeshlo's got some idea for this i beleive...
4. just implemented
5. win32, linux x86 + ppc, not sure about osx - no good exports yet, though
integratable? yes, and I hope so!
Aw, well, I guess that if someone actually wrote improved support for VL, anyone would be free not to use it if they didn't like it... Just as I'm free not to use NURBS if I don't want to, even though it's there for those who need it. When it comes to reasons for using raytracing, I'd say that line of reasoning is kind of off target. It's really all about the freedom to use another renderer, no matter what type it is.
And on the topic of Python as a "plug-in-language" it's totally OK if the API was complete. Is anyone working on this, or planning to? Oh, yes, Python is an excellent language, and incredibly powerful too.
Have you seen the O/S renderer http://www.aqsis.com/
mentioned on slashdot??
maybe that is an option??
Aqsis appears to be a plain vanilla renderman compliant piece of renderer with a standard feature set. I have not yet seen anything impressive made with it (if someone got something, post it please!).
The thing about VirtuaLight is the fact that it supports such an incredible amount of possibilities. It's a lot like Blender - complex, flexible and extremely well thought out. That's why VL is such a good choice. And there is actually a Linux version planned. Don't know when it's supposed to be released though, but it's coming.