Hi all

 

Today we're releasing the first Beta of what we're going to call Brazil 2.0 for Rhino Service Release 2.  Despite the innocent sounding name, this service release actually has a number of new features which bring the Brazil 2.0 for Rhino product into line with the "non-Beta" functionality of the 2.1 product for Max.

 

The new features in this build are:

  • New Brazil light dome with importance sampling and photon support.
  • Support for an unlimited number of processor cores (SR1 supports 8)
  • Geometry interference filter.
  • Sun target specification support and in-viewport sun position preview.
  • Several crash bugs fixed and hundreds of other minor issues fixed.
  • Rhino 5.0 64-bit support.

 

This beta is production ready - so you should find it very stable and complete.

 

You can download the new beta for 32-bit Rhino 4.0 / 5.0 or 64-bit Rhino 5.0 from here

 

http://brazil3d.ning.com/page/download-beta

 

Enjoy!

 

 - Andy

 

Views: 1306

Reply to This

Replies to This Discussion

OK - yup.  I will take a look.

Got it, works just fine. Thanks for the help.

 

Alan

Andrew le Bihan said:

Alan

 

I've figured out and fixed your problem.  There's a new 32-bit build up there ready for you to download - it should work fine on your other machines.

 

Andy


Alan Crighton said:

Andy,

I tried rolling back to earlier installation and it's giving me the same error message. I'll try and install on my home system and see if it work there, it may be I have an issue with my workstation...

 

Alan

Jonah

Could you be more specific - I've just tested a pile of script values, and they all seem to return the correct results even if no values have been set.

Andy

Jonah Barnett said:

Hi Andy. Remember about 2 years ago, I mentioned an issue with initializing the values of Brazil through scripting? The problem was, a value could not be returned (or modified) until you manually changed that particular value in Brazil's options dialog. this would need to be done manually for each setting which needs script access. I noticed the problem remains in the new beta (I haven't checked today's build). Can you take a look at resolving this? Thanks!

jonah

Yes.

Vicente Soler said:

 

BTW, is "linear workflow" working?

Can you explain exactly what the linear workflow toggle is doing?

 

For me it should do the following:

I set a document gamma (for example 2.2) and then all textures that are not HDR will have the gamma inverted (0.45) except for textures that have nothing to do with the final color of the object (bump map, displacement, etc.) AND also all colors that I select with the color swatches will have a 0.45 gamma applied to them.

 

I just want to confirm if it's doing exactly this or it's different.

 

This has little to do but: I also remember there was an annoying bug where if you modified a textures gamma, intensity, etc and then tried to update it using _Refreshalltextures, it didn't work. It was because every time you change a texture parameter it make a png copy of it in a temp file somewhere, and ofc that temp file wasn't being updated, only the original texture. This method of storing temp textures also makes the interface go really slow, specially on large textures. Isn't there a better way of doing this? 

 


Andrew le Bihan said:

Yes.

Vicente Soler said:

 

BTW, is "linear workflow" working?

Vicente

Yes - all of the above is true (all colors are gamma corrected) except that at the moment - in the build you have - HDRs and bump textures are also gamma corrected.  This will be fixed as soon as I get the next beta out.

Andy

Vicente Soler said:

Can you explain exactly what the linear workflow toggle is doing?

 

For me it should do the following:

I set a document gamma (for example 2.2) and then all textures that are not HDR will have the gamma inverted (0.45) except for textures that have nothing to do with the final color of the object (bump map, displacement, etc.) AND also all colors that I select with the color swatches will have a 0.45 gamma applied to them.

 

I just want to confirm if it's doing exactly this or it's different.

 

This has little to do but: I also remember there was an annoying bug where if you modified a textures gamma, intensity, etc and then tried to update it using _Refreshalltextures, it didn't work. It was because every time you change a texture parameter it make a png copy of it in a temp file somewhere, and ofc that temp file wasn't being updated, only the original texture. This method of storing temp textures also makes the interface go really slow, specially on large textures. Isn't there a better way of doing this? 

 


Andrew le Bihan said:

Yes.

Vicente Soler said:

 

BTW, is "linear workflow" working?

If you modify gamma, intensity - whatever - they should all change just fine.

Andy

Vicente Soler said:

Can you explain exactly what the linear workflow toggle is doing?

 

For me it should do the following:

I set a document gamma (for example 2.2) and then all textures that are not HDR will have the gamma inverted (0.45) except for textures that have nothing to do with the final color of the object (bump map, displacement, etc.) AND also all colors that I select with the color swatches will have a 0.45 gamma applied to them.

 

I just want to confirm if it's doing exactly this or it's different.

 

This has little to do but: I also remember there was an annoying bug where if you modified a textures gamma, intensity, etc and then tried to update it using _Refreshalltextures, it didn't work. It was because every time you change a texture parameter it make a png copy of it in a temp file somewhere, and ofc that temp file wasn't being updated, only the original texture. This method of storing temp textures also makes the interface go really slow, specially on large textures. Isn't there a better way of doing this? 

 


Andrew le Bihan said:

Yes.

Vicente Soler said:

 

BTW, is "linear workflow" working?

Ok. You mean it will be fixed in the next Rhino 5.0 beta, right? Not the next Brazil update.

 

I have a question about the domelight. What advantages does it currently have for it to be a 3d object. Does positioning it in different places have any effect? Can you use its position to control photons?

The Brazil (for 3dsmax) documentation seems to imply that it's a 3d object because it was expected in the future to be able to add some sort of volumetric effects that depend on its position.

If there are no advantages I would much rather that it was an option you could activate in the Brazil options. If you want to be more creative, make it, together with the skylight, a option inside the environment (in the advanced environment, for example). Also the document sun could be inside the environment so that you get to have multiple suns in a single document with different times of the day or different settings for interior/exterior, etc.)

You don't have to duplicate everything exactly as it is in the 3dsmax version. There are many outdated things interface wise that could be handled better, just take a look at more modern renderers. I also think it suffers greatly from "featuritis", but that's just me.

Andrew le Bihan said:

Vicente

Yes - all of the above is true (all colors are gamma corrected) except that at the moment - in the build you have - HDRs and bump textures are also gamma corrected.  This will be fixed as soon as I get the next beta out.

Andy

Vicente Soler said:

Can you explain exactly what the linear workflow toggle is doing?

 

For me it should do the following:

I set a document gamma (for example 2.2) and then all textures that are not HDR will have the gamma inverted (0.45) except for textures that have nothing to do with the final color of the object (bump map, displacement, etc.) AND also all colors that I select with the color swatches will have a 0.45 gamma applied to them.

 

I just want to confirm if it's doing exactly this or it's different.

 

This has little to do but: I also remember there was an annoying bug where if you modified a textures gamma, intensity, etc and then tried to update it using _Refreshalltextures, it didn't work. It was because every time you change a texture parameter it make a png copy of it in a temp file somewhere, and ofc that temp file wasn't being updated, only the original texture. This method of storing temp textures also makes the interface go really slow, specially on large textures. Isn't there a better way of doing this? 

 


Andrew le Bihan said:

Yes.

Vicente Soler said:

 

BTW, is "linear workflow" working?

Nope - next Brazil beta.

Vicente Soler said:

Ok. You mean it will be fixed in the next Rhino 5.0 beta, right? Not the next Brazil update.

 

Nope - position doesn't matter *for now* - it's correct that at some point in the future it might.

The only real advantage of having it as an object instead of a document property is that you can have more than one.

Vicente Soler said:

I have a question about the domelight. What advantages does it currently have for it to be a 3d object. Does positioning it in different places have any effect? Can you use its position to control photons?

I can't think of a scenario where i would need more than one at the same time. I can always blend two textures into one and it would probably be more efficient than having two domelights. Is there a way to more or less know or predict where photons are landing if we activate them in the domelight?

 


Andrew le Bihan said:

Nope - position doesn't matter *for now* - it's correct that at some point in the future it might.

The only real advantage of having it as an object instead of a document property is that you can have more than one.

Vicente Soler said:

I have a question about the domelight. What advantages does it currently have for it to be a 3d object. Does positioning it in different places have any effect? Can you use its position to control photons?

Could you at least have the dome light appear in the "lights" tab.

Reply to Discussion

RSS

Videos

  • Add Videos
  • View All

Members

© 2014   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service