Status of Yafray Rendering

General discussion about the development of the open source Blender

Moderators: jesterKing, stiv

leinad13
Posts: 192
Joined: Wed Oct 16, 2002 5:35 pm

Status of Yafray Rendering

Post by leinad13 »

What is the status of Yafray rendering being implemented into blender. I really like yafray as a renderer. But i cant seem to make any good stuff using yable and blender because i cant get my procedural materials to work i can only seem to create solid colours with different colours for their specularity and reflection etc...

I dont mean to push anyone but i think that this should be concentrated on, because i think Blenders scanline renderer is holding back our great piece of software.
-------------
Over to you boffins

L!13

eeshlo
Posts: 73
Joined: Wed Nov 06, 2002 10:02 pm

Post by eeshlo »

Well, I suppose I can say this now, but three months ago before I got sick, I was working on integrating yafray with Blender. The plan was to use yafray directly as a plugin as an alternative renderer (without discarding Blender's renderer of course). It was relatively easy enough to code builtin export, I also modified yafray to support all Blender texture mapping modes. By making use of Blender's mesh conversion, non-mesh objects where supported as well.
But I got sick and was unable to send the code to Jandro or others to extend this further, so it was never realised.
But in the mean time things have changed, 'nishin' has coded builtin yafray export to tuhopuu and a yafray/blender integration discussion forum was set up. From this forum it seems that most actually prefer a python script based solution, since this would also benefit other exporters. But direct integration has it's advantages as well (although through further python extensions some of these could be handled though python possibly).

So at the moment it is a bit undecided what direction to take.
We could use some more feedback (the few that responded in the forum sofar are mostly coders) on what others would like to see happen.
How would they like to see yafray supported in Blender?
I can imagine though that users don't really care about how it is implemented as long as it works without problems...

Landis
Posts: 0
Joined: Sun May 11, 2003 11:45 pm

Post by Landis »

eeshlo wrote:... I also modified yafray to support all Blender texture mapping modes....
Including Procedurals :shock: l?!?!?!?! Please tell me yes on this. Correct me if I am wrong but there is still know support regarding procedurals from anyone else at this moment... eeshlo your the heat buddy!!!! Also, I am by no means a programmer...the extent of coding I do is through using PHP forums such as this :roll: ...bracket over here...bracket over there...oops I forgot the slash...AHHHHH! Anyways, here is your non-programmers input on whether ot not to integrate the render or make it available via python to anyone who is reading this:

INTEGRATE THIS INTO THE DISPLAY BUTTONS...NO PYTHON!!

I have no problem using the python this and that for plugins and such...but most of your users are not going to be programmers or people willing to read long tutorials on how to get the damn file to import this and YABLE that. Its redicluous. This is a tool for artists not NASA engineers. PYTHON IS IDEAL FOR PLUG-INS BECAUSE OF THE LARGE NUMBER OF THEM AVAILABLE...BUT WE ARE TALKING ABOUT A RENDERER...HOW MANY OF THEM OUT THERE ARE AS CLOSE BLENDERS DEVELOPEMENT AS YAFRAY? Absolutlely not! I think that there should be a drop down option inside of the display buttons for YAFRAY's settings. As crazy as this may sound in terms of space in the interface, I can try and get Broken to whip up a mock up image regarding this. Nevertheless, there should be both a scanline option AND a raytrce option....scanline will always be needed for the developement phase simply for its speed to quality ratio....while YAFRAY yields results that are closer to a "finished product" or depending on your needs scanline may be good enough. Just my oppinion...now go ahead and tear it to shreads :cry: .

Cheers,
Landis
Last edited by Landis on Sun Aug 10, 2003 7:25 pm, edited 1 time in total.

wavk
Posts: 126
Joined: Wed Oct 16, 2002 9:58 am
Location: The Netherlands
Contact:

Post by wavk »

downsides of a python script:
-it's a script, so it's slow! Sometimes my render takes longer to export than to render!

-you have to load the script before you can render, very user unfriendly and not nice

-python problems, like blender version, python install and environment variables, in one word: user unfriendly (hm, that were two words)

pros of integration:

-fast
-settings can be stored within blender file!


A render display would also rock. :D (just mentioning it again, if I mention it enough, people will notice it)

Landis
Posts: 0
Joined: Sun May 11, 2003 11:45 pm

Post by Landis »

wavk... I strongly agree!!! Nicley put....I especially liked the comment regarding the export taking longer than the render...I was rolling on the floor I kid you not!!

Take care man.

hannibar
Posts: 50
Joined: Wed Oct 16, 2002 3:02 pm

Post by hannibar »

I totally agree with wavk. Python only gives you headaches with such complex scripts.
Yable does a good job, but it is way to limited for more complex things like shader creating. Hardcoding it CAN provide better solutions (eg crafter)

Landis
Posts: 0
Joined: Sun May 11, 2003 11:45 pm

Post by Landis »

Crafter really is a piece of work. It is going to be a nice application when it is finished. I cant wait!

Eric
Posts: 163
Joined: Wed Oct 16, 2002 1:01 pm
Location: Sweden, Norrköping

Post by Eric »

GO GO GO Eeshlo!

You're my god!

leinad13
Posts: 192
Joined: Wed Oct 16, 2002 5:35 pm

Post by leinad13 »

As you can see, most artists are not programmers and from the elysiun forums i gauge that they are impatient. They dont want to wait for an export, and then have to wait for the render. And they definatly dont have the right kinds of brains to set up a script. They have creative minds not problem solving minds.

Anyway i would really love to see yafray support built in simply, because Yable is ok, but it doesnt support procedurals, and it doesnt work with 2.28

I always have to go into 2.25 to get it to work.
-------------
Over to you boffins

L!13

ilac
Posts: 131
Joined: Mon Oct 14, 2002 8:24 am

Post by ilac »

leinad13 wrote:They have creative minds not problem solving minds.
:shock: A problem solving mind is a creative mind, and a creative mind is a problem solving mind.

i think artistic/irrational vs Logical/rational might be more suitable for what you're looking for! :wink:

Although, to be honest I think programmers are just as much artistic people. They need vision, creativity and good lateral thinking while still retaining a foot in the logical world! An artist is not bound to be rational although if you're using a computer and 3D program to express your art you too should have a foot still in the rational world! I'm sure a programmer is just as proud of his code as an artist is of his art! :D



Having said all that, I vote for integration too.

Less middle steps whenever possible! I see scripting as being an intermediate tool:
for temporary solutions,
for quick solutions,
for things which are constantly going to be evolving and changing,
and for things which the user might want/need to go in and dabble or tweak or add something.

if its something which is complete or relatively finate in its use like a renderer or a modelling tool, then I prefer integration or 'invisibility'. So something like a complete exporter should be integrated or at least run invisibly via a menu etc, like the proposal for the python menu in 2.29.

Money_YaY!
Posts: 442
Joined: Wed Oct 23, 2002 2:47 pm

Post by Money_YaY! »

intergrate baby!

I have spent countless times going to folders and files and windows to tset and see just one stupid image exported with a script.
I HATE THAT ! it is soooo slow to do.

Please intergrate !

^v^

eeshlo
Posts: 73
Joined: Wed Nov 06, 2002 10:02 pm

Post by eeshlo »

Landis wrote:
eeshlo wrote:
... I also modified yafray to support all Blender texture mapping modes....
Including Procedurals l?!?!?!?! Please tell me yes on this. Correct me if I am wrong but there is still know support regarding procedurals from anyone else at this moment...
I meant actual texture mapping modes: flat/cube/tube/sphere & uv/object/glob/etc.. As for procedurals like marble/wood/... these were simply handled by using a similar yafray procedural texture. Of course you don't get an exact match with the Blender procedural textures because it uses different code. But if you really wanted to have the exact same appearance for procedurals, then that wouldn't be a problem to code either, simply by using Blender's texture functions.
wavk wrote: -you have to load the script before you can render, very user unfriendly and not nice
I have seen idea's in the python development forum to handle this differently, like automatic loading of scripts and starting them from a menu.
wavk wrote: -python problems, like blender version, python install and environment variables, in one word: user unfriendly (hm, that were two words)
These too can be handled in python by including a subset of often used system functions in the Blender module so a full python install would not be necessary. JMS' povanim doesn't need a full python install for instance, although I'm not sure if this is still the case, I haven't catched up yet with the latest version.
wavk wrote: -settings can be stored within blender file!
Could already be done in python as well by making use of the Text module. Although it would be nice to be able to hide this data from the user.
wavk wrote: A render display would also rock. (just mentioning it again, if I mention it enough, people will notice it)
Can also be done in python by using opengl, I did the same in my LF export script which displayed the result while rendering in a Blender window.


ok, enough quoting, the problems I have seen mentioned sofar regarding python are basically caused by the current state of the python api, it simply isn't complete yet. But development is very active and lots of the problems mentioned could be resolved by improving/extending the python api and Blender's handling of scripts, which would not only benefit yafray export but any other Blender script as well.

I don't want to sound as if I see python as the way to go, I started to code for integration after all, I just want to make clear that all the problems mentioned don't necessarily mean that python is not up to this task, and I just like to defend the 'other' view, even if I think differently.
Also, besides yable there are other yafray exporters, and I can imagine the developers of these scripts to be strongly in favor of python support, they don't want to see their work discarded....

The main real advantage of python is fast development/bugfixes, while direct integration would mean bugfixes would depend on new Blender releases.

In any case, since direct integration seems to be strongly favoured, I can always just continue where I left off. We can at least try to create a working prototype for people to test with, so people can try it out and guide us in further development with their opinions.
In the mean time you still have to use python, or use the builtin tuhopuu yafray exporter, which I didn't try myself yet, but could already give you a glimpse of what it would be like.

Now, if I just could get Blender to compile again I could actually get back to work on this, but since I'm also not a 'real' programmer...

jandro
Posts: 0
Joined: Mon Aug 11, 2003 2:07 am

Post by jandro »

Well, eeshlo is more than a real programmer :-)

By extending blender python api, we could totally hide a python script from the user, so he could just go throw materials, lights and so changing values and having a special key (for example) to show yafray extra params (by calling the script in some way).

I also like the idea of total integration. If the code is kept in a separate file and compiled with blender it wouldn't disturb so much. But it seems coders don't like this idea. We could even keep much of the exporting info in a config file to avoid adding code to blender each time we improve something in yafray.

So I think both ways could be possible, maybe direct integration could get faster results. In the other hand a python script is easier to maintain. But blender coders have to choose. Of course taking into account all these user requests.

Yafray integration forum is a bit death, don't know why. We should resume the disscusion with the coders.

Landis
Posts: 0
Joined: Sun May 11, 2003 11:45 pm

Post by Landis »

eeshlo wrote:
I meant actual texture mapping modes: flat/cube/tube/sphere & uv/object/glob/etc..

THAT is what I meant by procedural baby...and you are in there man....dude....I already have a fully textured airman just waiting to be ran through your work...is there a way that you can export your work as a script now that all of us have bad mouthed it :wink: ? If not for me do it for the Airman...c'mon..look... :cry: he's crying . :wink:

Cheers,
Landis

sten
Posts: 177
Joined: Sun Oct 13, 2002 7:47 pm

Post by sten »

GO GO GO

damn, how long must we wait for integrating a raytracer into our 3D tool, any other big 3d tool has it....

so just start CODE !!! ;)

I would love too see it, is it possible to make a hybrid rendered, so we dont need to use raytracer on certain objects on a scene?

good luck !! :D

Post Reply