Previous Thread  Next Thread

chat icon Problems with VL and Publisher

CrazyMopho

Posted: Fri Oct 18, 2002 12:07 am
Joined: 18 Oct 2002
Posts: 1
The export script for Virtualight does not seem to run under Publisher 225 Crying or Very sad
Reply with quote


Jamesk

Posted: Fri Oct 18, 2002 8:02 am
Joined: 14 Oct 2002
Posts: 239
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...
Reply with quote


G_Man

Posted: Fri Oct 18, 2002 8:08 am
Joined: 14 Oct 2002
Posts: 19
Quote:
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!!! Very Happy

That is what open source is all about

-Geoffrey-
Reply with quote


Jamesk

Posted: Fri Oct 18, 2002 10:45 am
Joined: 14 Oct 2002
Posts: 239
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...
Reply with quote


MrMunkily

Posted: Fri Oct 18, 2002 8:59 pm
Joined: 14 Oct 2002
Posts: 79
Lightflow, for now, is dead.
Reply with quote


sedgetone

Posted: Fri Oct 18, 2002 9:04 pm
Joined: 17 Oct 2002
Posts: 49
VL is great if your a Micro$oft abuser, what about the rest of us Exclamation

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.

Sedgetone
Reply with quote


nikolatesla20

Posted: Fri Oct 18, 2002 9:59 pm
Joined: 13 Oct 2002
Posts: 25
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?

-nt20
Reply with quote


MrMunkily

Posted: Fri Oct 18, 2002 11:35 pm
Joined: 14 Oct 2002
Posts: 79
Listen!

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

Virtualight:
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.

Lightflow
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
Pov-Ray
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...

Yafray
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!
Reply with quote


Jamesk

Posted: Sun Oct 20, 2002 5:05 pm
Joined: 14 Oct 2002
Posts: 239
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.
Reply with quote


G_Man

Posted: Mon Oct 21, 2002 12:38 am
Joined: 14 Oct 2002
Posts: 19
Have you seen the O/S renderer http://www.aqsis.com/ mentioned on slashdot??

maybe that is an option??

~Geoffrey~
Reply with quote


Jamesk

Posted: Mon Oct 21, 2002 6:53 am
Joined: 14 Oct 2002
Posts: 239
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.
Reply with quote


 
Jump to:  
Powered by phpBB © 2001, 2005 phpBB Group