Page 1 of 1

Problems with VL and Publisher

Posted: Fri Oct 18, 2002 1:07 am
by CrazyMopho
The export script for Virtualight does not seem to run under Publisher 225 :cry:

Posted: Fri Oct 18, 2002 9:02 am
by Jamesk
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...

Posted: Fri Oct 18, 2002 9:08 am
by G_Man
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!!! :D

That is what open source is all about


Posted: Fri Oct 18, 2002 11:45 am
by Jamesk
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...

Posted: Fri Oct 18, 2002 9:59 pm
by MrMunkily
Lightflow, for now, is dead.

Posted: Fri Oct 18, 2002 10:04 pm
by sedgetone
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.


Why plugins? I do not agree.

Posted: Fri Oct 18, 2002 10:59 pm
by nikolatesla20
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?


Posted: Sat Oct 19, 2002 12:35 am
by MrMunkily

why would you want to use a raytracer?

1. reflections
2. refraction
3. global illumination
4. classic interior radiosity
5. compatability
6. license (yes it does matter)

Lets see how they stack up:
OK means no complaints

1. OK
2. OK
3. Seems to have artifacts and is tremedously slow...
4. OK
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.

1. OK
2. OK - really quite nice in fact
3. Nice, but still artifact-prone, and slow
4. Excellent
5. Linux x86 and Win32 only
6. non-commercial use only. poop.
no development in almost 3 years.
integratable as of now? no
1. OK
2. OK
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...

1. OK
2. OK
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
6. GPL
integratable? yes, and I hope so!

Posted: Sun Oct 20, 2002 6:05 pm
by Jamesk
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.

Posted: Mon Oct 21, 2002 1:38 am
by G_Man
Have you seen the O/S renderer mentioned on slashdot??

maybe that is an option??


Posted: Mon Oct 21, 2002 7:53 am
by Jamesk
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.