Brazil V2.0? True or Gossips?

[cozdas]

Hi,

Brazil 2.0 is under full-speed development but there's no announced official ETA yet.

here (http://www.splutterfish.com/sf/sf_gen_page.php3?printer=1&page=sf_roadmap) you can find a brief explanation about the development status, and here (http://www.splutterfish.com/sf/tech_gallery_index.php) you can preview some of the announced features of v2.0. Please note that some of the features in that page are already available for Brazil 1.x too.

[cpiboontum]

Hi Cozdas:

Thanks for the quick response

:) That is truely great to hear that V2.0 is on its way. This is the first time I saw your website with amazing rendering illustrations. So I guess I have two questions for you. I see some amazing stuff you guys had on your website with V1.0 but in V2.0 demontration, if I am correct, you are just tweaking basically better animation handling such as motion blur, large number of polygons, and displament mapping. Are these developments for V2.0 to enhance V1.0 or a complete makeover in its algorithm and the way Brazil V2.0 calcuate lighting and rendering including user interface.

To top the above question, do you guys have any upgrade special in mind for cusotmer who has V1.0 or is planning to purchase V1.0 so near to V2.0 release?

In anycase you guys so far seem to have sold me on the quality of lighting algorithm and rendering. Just need to explore a little more and compare. You may hear from me soon :):):). Thanks

-VISuAL3DFX

[ZeBoxx]

Howdy,

To top the above question, do you guys have any upgrade special in mind for cusotmer who has V1.0 or is planning to purchase V1.0 so near to V2.0 release?

Yes.

Are these developments for V2.0 to enhance V1.0 or a complete makeover in its algorithm and the way Brazil V2.0 calcuate lighting and rendering including user interface.

They are largely enhancements of v1.0 . Brazil r/s was designed from the beginning to be extremely flexible at the core, so that additional functionality can be added in stable ways.
That's not to say there won't be some major overhauls, though. E.g. the single-frame distributed network render will completely change.

- How lighting is calculated - should remain the same, though other GI systems may be added.
- How 'rendering' is done. If you mean the basic raytracing - there will be a few interesting (de)velopments there.
- If you mean image sampling - Brazil r/s' image sampling method already kicks serious butt, no need to mess about with it. Again, not excluding any possibly work on alternatives.
- The UI. There won't be many changes. The Brazil r/s light will be changed slightly to facilitate IES support (as you may have seen in the tech preview gallery). Other than that, things should remain largely the same. The Brazil r/s component interfaces already work very well in terms of workflow (a good deal of attention is given to them), so I doubt there will be any major changes there.

That all said and done - all the above may be void at a whim, as there simply hasn't been any official v2.0 announcements (short of the tech preview gallery information). But I do believe that is the current state of affairs :)

Best regards,
Richard Annema

Edit: Pselling fix

[cozdas]

Hi,

Brazil 2.0 is continuation of Brazil 1.x and will be 100% backward compatible with it if that's what you're asking. We just "forked" the development after 1.0 release so that we can add new fetures to 2.0 without breaking 1.x robustness which customers rely on for production... 1.x branch is mainly hosting bug-fixes and relatively small feature additions (like the skin shader (http://www.splutterfish.com/sf/gallery_view.php?photo_id=356&screen=0&cat_id=2&action=images) which is added in v1.0.14). Brazil is a quite modular software internally, so no complete re-write is needed and will not be for a long time ;)


So far announced features, which are planned to be placed in v2.0, are:
- 3D Motion Blur
- Displacement mapping
- Massive Instancing
- Photometric light support
- (More!) Improved shadows

needless to say that there are bunch of other features we are working on which we prefer not to talk about yet.

As for pricing and upgrade options they'll be announced when they are determined; stay tuned :)

Regards

[cozdas]

Ah ZeBoxx was faster than me to reply :eek: ... Anyhow I won't delete my post :shrug:

[ZeBoxx]

:surprised You need more coffee, cozzy! :thumbsup: :D :bounce: :bounce: :bounce: :bounce: :bounce:

[cpiboontum]

:):):) You guys have been great and quick to respond :):):) Definately 100 :thumbsup: for customer care :applause:. I understand about not being able to release a lot of information. I guess my decision will be made on the current version but hopefully if I do purchase version 1.0 I will also get the benefits of version 2.0 also. Thanks again.

Best Regards,

-VISuAL3DFX

[emack]

I have heard some plans for a standalone version of Brazil . . could someone discuss how this would probably work?

It seems that Brazil has very specific lighting and material properties to achieve photometric accuracy, and I'm curious how a given external application would go about creating a Brazil-readable file while still allowing some degree of render preview etc. Autodesk Viz uses IES standard lights, but I don't think Lightwave, EI, Maya, or XSI do.

Would you have to create an interface for each application as tightly integrated as the MAX interface?

Thanks,

Eliot

[ZeBoxx]

Hmpf.

Lost a perfectly good reply thanks to the server being too busy.

In short : Yes, to take advantage of the full capacity of the Brazil r/s renderer, one will likely have to have systems in place that can access the features of interest.

In the case of IES lights : If an application doesn't support IES lights in any way, I can't imagine it could export them to the stand-alone renderer, and thus you wouldn't be able to render them.
Either SplutterFish or a 3rd party would 'have to' create support for that.
For 3ds max, SplutterFish already offers the components to access the features - Brazil r/s max is a suite of tools, not just a renderer :)

Best regards,
Richard Annema
*copies the above to clipboard - just in case*

[emack]

Have you thought about supporting the Kaydara Filmbox file format for the standalone version? It seems to offer a great deal of interoperability between the various 3D packages.

One could have a FBX->Orchid converter that then fed into the standalone. A bit clunky compared to the max integration, but perhaps as a 'placeholder' until the full integration is in . . .

I don't know how close FBX and RIB/Orchid formats are; this may or may not make sense :)

Eliot

[ZeBoxx]

Heya,

This may or may not have been given thought - along with rib files, xml, and who knows what else :)

Suffice to say that the skeletal format for carrying the data would be the least of the worries ;)

--=( Off-Topic)=--
It's interesting that you should mention FBX, though;
I was under the impression that Maya supports it - I know 3ds max.. somewhere.
Yet everytime somebody asks how to get data from Maya to MAX, the .obj export route is suggested.
Maybe I'm missing something ;)
--=( /Off-Topic)=--

Best regards,
Richard Annema

[beaker]

There is allready atleast 1-2+ rib exporters for most professional 3d apps(except XSI). So as long as orchid fully supports it, anyone will be able to make a connection between the two. Liquid, MTOR, MayaMan for Maya, Lightman for LW, Houdini supports rib out of the box, etc....

[ZeBoxx]

Hi Beaker,

As true as that may be - a .rib exporter won't help much if the host application doesn't support a particular feature (given:IES) in the first place.

Hence why although that would indeed offer at least a base for compatibility, it does not offer access to the full complement of features in Brazil r/s

Hope that makes sense :)

Bst regards,
Richard Annema

[chet2]

For what it is worth i have a few thoughts.

First of all i totally understand where richard is coming from on a few of his points.

1. The whole issue of supporting RIB.

Yes it would be good because so many apps support RIB export. However if you have ever used it you'll see that it is heavily biased toward prman's architecture. Brazil shouldn't mirror it's architecture and feature set, simply to adhere to the RIB spec. Personally I would be much happier if splutterfish created an ascii Brazil spec (based on C, python or something else simple). This way users of different applications could write their own exporter. I won't say it is trivial,but it is pretty easy to write simple scripts to output ascii files from most 3d apps. More developed bullet-proof plug-ins would take longer, but you could hammer out simple scripts in a couple of days.

2. The issue of using a translator such as FBX

Currently the filmbox format has support for many existing 3d apps. It is a great "hack" to swap files between apps. However for a larger facility it is a little sloppy to be considered a proper pipeline. Additionally since filmbox has to support all the newest versions of all the softwares there will always be some bugs and unsupported features. Also it is important to remember that, unlike FBX, renderers don't care about things like skeletons, deformers and IK. The job of a renderer is to draw. Renderers only care about lights, shaders and geometry. To this end i refer back to the simplicity of a brazil spec.

I imagine it would be really easy to retool something like "liquid" or "softman" to spit out some kind of ascii brazil files. Ideally this means that splutterfish doesn't have to be burdened with writing and supporting translators for every app on the market. Given the price difference to PRMAN and Mental Ray, I believe any studio would be happy to R+D a translator. Conversely, I think many would be hesitant to pipe all their shots through 3D max, if they have a different pipeline.


So what do you guys say about an ascii spec for 2.0?
Maybe for siggraph?

I haven't used brazil yet so I could be way off base, but i thought i would share a couple of thoughts.

c

[beaker]

just like entropy and bmrt, they could add extentions to the renderman language to support those features that they need to add. The guys at Animal Logic were pretty good at adding support for any extra features in Mayaman and Maxman.

[chet2]

This is where it becomes a bit of a grey area. Currently there are several rib compliant renderers. If each add extensions "ad hoc", it ceases to be a standard. Really it is about weighing the pro's vs. the cons. The main pro for rib compliance is that there are several rib translators.The main con is that the rib spec may not fit with a certain renderers paradigm. Say for example you don't deal with LOD via bounding boxes or don't describe lights as shaders. The key is to ask, what do you really gain by making brazil rib compliant?

Apart from really simple adoption there is no reason I can see for brazil not to have it's own spec. For example mental ray has it's own file format and has wide acceptance.

again just my 2 cents

c

[ZeBoxx]

Heya,

I have to say.. I disagree.

Adding extensions to a specification or language does not affect the specification/language in its very essence, as they are extensions.

Example case being HTML.
Many developers/browsers extended the HTML format to their own liking, and this generally did not cause any problems on other platforms as the HTML specification explicitly says that browsers/editors should -ignore- tags and elements they are not familiar with.

Eventually some of the extensions made their way into future version(s) of the specification, though.

I think there's nothing wrong with extending a format in this way.

However, I will say that I would prefer it that if any extensions were added that they would at least be indicated as such by a developers/product identification of sorts.

e.g. rather than just subSurfaceDepth, call it bzSubSurfaceDepth, or subSurfaceDepth_aqsis, etc.

That way there can be no future conflicts should a "subSurfaceDepth" name make its way directly into the specification.

Just my €0.02

[CGTalk Moderation]

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.