View topic - Yaf(a)Ray, on the way to release candidates

Yaf(a)Ray, on the way to release candidates

Users-contributed CVS development builds. Post here your questions about compiling the source code.

Post Fri Mar 21, 2008 2:41 pm

These are my views on that matter and I talk now as a member of the YafRay team:

I see a lot of people still using YafRay 0.0.9.

However, the future of YafRay is called Yaf(a)Ray, which is a completely different render engine. Actually removing YafRay 0.0.9 plug-in in Blender will make little difference for us which already use Yaf(a)ray or in another words, YafRay 0.1.0, which is in many aspects a more advanced and radical design than the YafRay 0.0.x series.

So the only alternative we have IMO, and the best we can do for this project now is using Yaf(a)Ray and demostrate what can be done with it.

The movement of the Blender Foundation is expected and it was going to happen sooner or later. We have none one to blame but ourselves. Nonetheless, I hope they do it with tact and elegance. The YafRay Gallery is a good testimony of YafRay services to the Blender comunity during several years.
User avatar
Samo
 
Posts: 3105
Joined: Tue Dec 20, 2005 10:39 am
Location: Spain

Post Fri Mar 21, 2008 3:57 pm

OK! We want to use Yaf-A-Ray, BUT, I for example using open SuSE linux and can't find suse build of YaR. Ubuntu - yes! MF Windozza - yes! Mac - yes! openSuSE - no!
Old Yaf-Ray 009 have universal *.rpm installer - it`s very useful!
So, coders need artists help (using and instaling), but can't hive them easy instalator!
Can anybody create in DOWNLOADS something like UNSTABLE or TESTING RELEASE.
In that folder we will look for Yaf-a-Ray buolds, Scripts, and special Blender builds for ALL OS.
Because now we must search this fils in different places in forum.
User avatar
Yaroslav_L
 
Posts: 213
Joined: Mon Feb 19, 2007 6:27 pm
Location: Poland - Gdańsk

Post Fri Mar 21, 2008 9:42 pm

Thanks for your views, Samo, which I share, except:
Samo wrote:Actually removing YafRay 0.0.9 plug-in in Blender will make little difference for us which already use Yaf(a)ray

But how would you invoke Yaf(a)Ray from Blender if the YafRay Blender plugin is disabled? That was my concern. Or would the Blender plugin files that come with the Yaf(a)Ray source (which we have to copy over to the Blender source tree) take care of that?
Sanne
 
Posts: 97
Joined: Fri Oct 05, 2007 4:50 pm

Post Sat Mar 22, 2008 2:25 pm

I may have found a bug with anisotropic reflection in coated glossy material. When I use it on a subdivided object, the subdivisions show up in a weird way:
Image

Here's the blend (ca. 1MB due to background image).

This happens Yafaray revision 196 with boiko's patch and Blender revision 14109.
Sanne
 
Posts: 97
Joined: Fri Oct 05, 2007 4:50 pm

Post Sat Mar 22, 2008 3:39 pm

Samo and everyone in the dev. team;

As a user's point of view (not programmer's), I really don't mind if Yaf(a)ray
will be shifted within the new Blender version as a built-in renderer or not.
As long as Yaf(a)ray exists and there's plugin that works as an exporter
(maybe...as Indigo) for a new official Blender release.

Yaf(a)ray is great renderer considering it's a bias and a free one. If it requires
some extra steps for me to use Yaf(a)ray (or Yafray 0.1.0) then, .... why not?

Again, thanks for this free amazing renderer. Keep up the good work.
Cheers.

Pentium4 3.0 HT, 4 GB ram, Windows XP 32bit.
Blender 2.46, YafaRay 2.0.2
palawat
 
Posts: 55
Joined: Wed Jan 09, 2008 4:21 am
Location: Bangkok, TH

Post Sat Mar 22, 2008 3:53 pm

Sanne wrote:Thanks for your views, Samo, which I share, except:
Samo wrote:Actually removing YafRay 0.0.9 plug-in in Blender will make little difference for us which already use Yaf(a)ray

But how would you invoke Yaf(a)Ray from Blender if the YafRay Blender plugin is disabled? That was my concern. Or would the Blender plugin files that come with the Yaf(a)Ray source (which we have to copy over to the Blender source tree) take care of that?


We can always patch Blender, regardless of what the Blender Foundation does so the last option you mention is the most likely scenario
User avatar
Samo
 
Posts: 3105
Joined: Tue Dec 20, 2005 10:39 am
Location: Spain

Post Sat Mar 22, 2008 5:52 pm

Ah, great, Samo, thanks for your answer. I can calm down now. :)
Sanne
 
Posts: 97
Joined: Fri Oct 05, 2007 4:50 pm

Post Sat Mar 22, 2008 6:03 pm

I always considered Yafray was privileged compared to other render engines because it was tightly integrated in Blender (even if it was no more the case with Yafaray but I was expecting this could change in the future).

I started with Blender and then came to yafray. I'm afraid that once it has been removed from blender, few people follow the same way as I did...
doodle
 
Posts: 39
Joined: Fri Apr 20, 2007 10:37 am
Location: Cannes (France)

Post Sun Mar 23, 2008 12:05 pm

I always considered Yafray was privileged...


That is not true. YafRay was started almost six years ago. At that time no one else:
a) bother to code an open source raytracer.
b) bother to integrate it into Blender
c) Blender was not as succesful as it seems to be now
d) the integration was demanded by the Blender comunity and was part of Blender code with the approval of the BF.

So it is quite a different case than most recent render engines.

even if it was no more the case with Yafaray but I was expecting this could change in the future


The break up is inevitable and not necessarily bad for Yafray future. It is a fact that the integration in certain aspects shaped YafRay 0.0.x series and on the other hand limited its development in the sense that not every thing that was coded could be implemented in the plug in and therefore appear in Blender panels. And many times YafRay coders just tried to support Blender features instead of exploring new routes. This model has been valid for a time, and the result is what you can see in the YafRay Gallery (and in the Blender gallery too), but this model not longer works. Besides, integrating YAf(A)ray in Blender as YafRay is difficult and politically incorrect.

The fact that yaf(A)ray follows a more indepent path now means that we can implement features with lesser bothering about Blender.

A render API is needed. IMO It is not entirely true that the render API the BF talks about is meant to benefit all external engines, the render API aim is mainly integrating a renderman compliant engine into Blender (Aqsis) using a politically correct method (render API), a method other external engines can benefit from (YafRay etc). So unless Aqsis & the BF get serious about it, there isn't going to be render API for quite a while IMO, which would be bad for us.

I'm afraid that once it has been removed from blender, few people follow the same way as I did...


We should not be afraid of competition. It will be make us stronger or it will definitely kill us if there are other options better than YafRay.
Last edited by Samo on Mon Mar 24, 2008 12:40 pm, edited 3 times in total.
User avatar
Samo
 
Posts: 3105
Joined: Tue Dec 20, 2005 10:39 am
Location: Spain

Post Sun Mar 23, 2008 7:48 pm

Samo wrote:Actually removing YafRay 0.0.9 plug-in in Blender will make little difference for us which already use Yaf(a)ray...


Thanks for your elaboration on this issue, Samo. However, I'm not entirely put at ease yet as the tight integration of Yafray into Blender has always allowed me to use more of Blender's functionality than what I have been able to use with the Yaf(a)ray-patched Blender. To name an example: because the Yaf(a)ray plugin uses its own material settings I'm not able to produce animations in which material properties change over time. So, if I were to animate a chameleon changing the colour of its skin, I currently would not be able to do this with Yaf(a)ray.

I understand that both Yaf(a)ray as well as the Yaf(a)ray Python script/patch currently are work-in-progress, but do you think that you eventually will be able to restore functionality like this while keeping Blender integration limited to a 'mere' patch?
TommyCP
 
Posts: 1
Joined: Sun Mar 23, 2008 7:26 pm

Post Mon Mar 24, 2008 12:03 am

Sanne wrote:I may have found a bug with anisotropic reflection in coated glossy material. When I use it on a subdivided object, the subdivisions show up in a weird way:


Funny one indeed, it is related to some numerical inexactness, where normal values should be zero but are in one case about +1e-8 and in the other -1e-8. I patched this (see below), but am not sure if the patch does harm to other things (don't think it does). The better way would be to actually patch the coated glossy code, but that is ... somewhat hard to read without knowing which papers Lynx used.

Anyway, add these lines to include/yafraycore/triangle_inline.h:

Code: Select all
inline void triangle_t::recNormal()
{
   const point3d_t &a=mesh->points[pa], &b=mesh->points[pb], &c=mesh->points[pc];
   normal = ((b-a)^(c-a)).normalize();
   if (abs(normal.x) < 1e-5) normal.x = 0;
   if (abs(normal.y) < 1e-5) normal.y = 0;
   if (abs(normal.z) < 1e-5) normal.z = 0;
}


I think this should be correct anyway most of the time. Btw, if you just slight rotate your box, the error doesn't show. While investigating, I found another bug, seemingly related to the kdtree, that shows up as holes (missed ray-tri-intersection) but that only happens when there is nothing but a plane in the scene (which is a unlikely scenario anyway).

In other news, I spent some time on integrating volume rendering (participating media) into yafaray, here you can see two *very* first results:

Image

Image

Well, and maybe a few words to the Blender-Yafray thing: The problem is, that the yafray integration is some hardcoded ... something. Of course we could make a patch for Blender, that completely exchanges all of Blender's functionality with the appropriate yafray counterparts since we need to patch Blender's code now already. But if we do this, we completely decouple yafray from Blender and this would narrow the amount of yafray users even more. There would probably be no way back. When I wrote the python script, I hoped that Lynx' new export code would eventually be integrated into Blender but at the same time I assumed the Yafray part of the Blender UI would not be updated anymore. With this assumption I wrote the python UI. As it seems now, nothing from Yafray in Blender will ever be updated again. ;-)

As this is so, I think we won't see Yaf(a)ray integration into Blender's UI soon, unless someone does the work and writes a patch that does the same thing I did with the python UI. Stuff like animating texture parameters and so on of course relied on that (unless you can convince the Blender ppl to allow ID property keyframes, that would also solve your problem).

Worst thing for me is, that Yafray pretty much is already no longer part of Blender (besides the little part of export code, which we already have to patch and is not part of official releases of Blender). You could argue that then it makes no difference anyway. And maybe that is correct ... well, I don't know. I would rather hope, that either Blender people will once again allow Yafray specific contributions to their code or that they will finally put together a render API that would be usable for all 3rd party renderers. The current state is by far the worst possible, it's pretty much like hanging in the air.

So long,
Bert (finally having made the way to the forum registration ;-))
bert_b
 
Posts: 265
Joined: Sun Mar 23, 2008 11:31 pm

Post Mon Mar 24, 2008 1:14 pm

Hi Bert,

thanks for looking into the bug. I recompiled yafaray with your changes, and now I get this:
Image
Then I also recompiled Blender (is it needed?), but I get the same result.

Your volume rendering work looks amazing!! I'm looking forward to it.

As for the Blender integration, as long as there's no Blender render API, I would prefer the situation as it is now, meaning: patched yafray export code and python script. A fork of Blender doesn't seem wise to me. On the other hand, as long as a special build is needed for Yaf(a)Ray, there might not be enough users willing to use and test it.

At the end you developers decide, whatever is most managable for you in this situation, I guess.
Sanne
 
Posts: 97
Joined: Fri Oct 05, 2007 4:50 pm

Post Mon Mar 24, 2008 1:52 pm

I agree with Sanne - artists are NOT CODERS!
Patching, compiling, hacking - it`s not for me. But I'm not stupid - I'm magister of light techtik, and now I'm learn architecture.
A have no time to learn coding languages and patching rules.
But I want to use Blender+YaR. Everybody want!
So please!!! Please - give us easy instalators for main linux distr, Mac OSX, and...
No Windows users have only 1 bonus - easy *.exe inst...

:lol:
User avatar
Yaroslav_L
 
Posts: 213
Joined: Mon Feb 19, 2007 6:27 pm
Location: Poland - Gdańsk

Post Mon Mar 24, 2008 2:56 pm

Sanne:

Recompiling Blender was not necessary. Although I do not get your results:

Image

When I wrote "add these lines" I of course only meant the 3 lines checking the normal for near-zero values. I'll look into it again, but it's not easy because I can't recreate the problem now.

Yeah, I wouldn't like a fork either, and I won't do it anyway, so if noone else does it, there is none. ;-)

Yaroslav:
I heard there are some artists who also know how to code and vice versa. ;-)

For easy installation packages: Since Blender needs to be patched, we can't really do this for Linux distros, since it would overwrite their (official) Blender executable unless we change names and so on (but we could just give you tar.gzs that will put themselves into /usr/local/ or something). For Windows it would be possible the way Lynx did it, but I have never compiled yafaray on Windows (or Blender for that matter), so someone who knows what to do would be good here. For MacOS, we might have boiko, dunno yet.
bert_b
 
Posts: 265
Joined: Sun Mar 23, 2008 11:31 pm

Post Mon Mar 24, 2008 3:01 pm

Yaroslav_L wrote:I agree with Sanne - artists are NOT CODERS!

I have to chip in here a bit... that's not exactly what I meant. You really don't have to be a coder in order to compile stuff when there are good instructions how to do it. What a developer does is much much more. While it may be inconvenient, everybody who is able to read and write should be able to do a compile of Blender and Yaf(a)Ray.

It's a bit work, maybe even some hours on first try, yes, but just think about what enourmous work the developers do for us. To ask them to also do the several builds for several OSs for us would be a bit much. And also that is time they won't have for coding.

That said, I don't know how difficult building is on Windows, I only know about the process on Linux. Luckily there exist some builds for Windows and also some Linuxes in the first post of this thread..
Sanne
 
Posts: 97
Joined: Fri Oct 05, 2007 4:50 pm

PreviousNext

Return to Testing Builds



Who is online

Users browsing this forum: No registered users and 8 guests