Bifröst

#29

Thx for precision Raffaele !

Now we need a screenshot :). It’s pretty embarrassing but … i’m impatient to discover a new AD features … it hasn’t happen since Maya 2009 and nParticles ! :slight_smile:

#30 
    I have a different opinion than you have. Get over it, and please spare us all the pathetic polemics. lol
        
        "Maya" has nothing do with VFX/Games and "Blizzard" nothing with a games company? Just how uneducated and dense are you exactly? Both names actually do have lots to do with the respective uses/ventures both in terms of meaning and spirit. Actually, I'm having difficulty not being able to solidly connect any name of any piece of software etc to it's purpose just by interpreting the naming. That's what is called "good marketing"! 
    
    Beef-rösti (aka swiss hash-browns with beef) ... sorry.... Bifrösti kind of eludes me in terms of its associative meaning and marketing potential, so I asked for a conclusive explanation. Anyways, since you're obviously unable to deliver and Raffaele was the one to actually provide some more insight in a civil manner instead, I suggest you go fix some bugs instead of trolling around, pissing at people just because the don't share your likes/dislikes. And, gee, get some manners and education while you're at it, buddy! 
        
        Cheers!
#31

Lets keep it friendly folks.
Besides… It’s Friday! :bounce:

#32

Don’t hate me I’m just leaving these quotes here. A couple from this thread and the last from Autodesk last November.

Bifrost is not just a fluid sim (nor was Naiad intended to remain one), it is supposed to be a procedural platform. It’s also not part of Maya, it’s its own platform, just it was shown hooked into Maya as that’s the first and most natural option for them.

it’s the Norse equivalent of the bridge between earth and heavens, or human and gods realm really.

Our portfolio has almost 200 pieces of software. Right now, we are moving some apps (collaboration and analysis tools) to the cloud. Our long-term strategy is to move everything there.

:argh:

#33

Bifrost is a development code name, as far as I know.

#34

It’s also not part of Maya, it’s its own platform

That’s potentially can be not very good.
It can be like “program in program” and not work with some maya features. :shrug:
So it’s fit in what i posted above - there are no necessary to put it in maya from beginning.
But who then update Maya license’s if user can buy standlone platform separately…

Good if somebody share more info :buttrock:

#35

well to me it’s a clever choice cause …

  • trying to implement a VEX low level control in maya is gonna be pure PITA for AD engineers.
  • i am not an API expert but the way maya do connections beetween operators is not as clean as in H , thus implement such a system with hardcore stability is again PITA (impossible ?)
  • they have just buy a low level system coded by 2 of the best engineers in the world nordenstam+bridson
    that is already shinning
  • maya Code is i guess far more complex to maintain and make evolve without breaking other feature …
  • so if you outpout all the dynamics FLUID/RBD/SBD/PARTICLES/ in an external apps , coded by 2 bright guys , chance are that things are going to evolve faster than in maya.
  • this apps can also be link to other AD apps
  • Maya Dynamics is a mess you have tons of solver + pluggins that are not interacting together, trying to connect Bullet + Dmm + nDyn + Fluids + nCloth + Hair etc with the new dyn system is close to impossible, and if there are brave man at AD to meet the challenge, the result is going to enter quickly in the guiness record of unstability …
  • come one Marcus ! make something BIG ! we will have 2 Bazooka for making our shots H+Bfrost … :slight_smile:
#36

But if they add a completely independent system that can do all dynamics what a sense then developing a Nucleus?
Paying to Naiad team and Nucleus team would be nonsense cos they technically will exist in one package.

#37 
 You make a good point igor ! but if maya wan't to compet with H , it has to have this low level data access all along the tree. And i don't know how AD engineers could implement this in maya, only 3 options to me.
 - rewrite the core from scratch 
 - try to create a virtual layer that give you the illusion that you have the VEX low level control (but in reality they are not acessing directly the basic function only binding ... so its slower)
 - output all pre-FX geo in an external app that deal perfectly with low level data and use nucleus has a cloth / hair fx tools for the CFX guys

SESI is going really really fast, so they have to find a way to focus their team on features dev and not on debug … and focusing on an external tool coded by 2 genius , is the easiest way to go ( well i guess ? ) :slight_smile:

#38

Excuse me for my misunderstanding, I’m still a novice… but what about ICE ? Doesn’t give this low level control or what else? It’s in Softimage of course but also it’s in AD for a long time

#39

ITT: People who don’t know about software development talking as experts on codebases they have never seen.

#40

i would say talking as a technical user … :).

#41

@Cheesestraws - topic looks much nicer with you in Ignore list.

The Bifrost in total can be as DOP context in Houdini.
Mesh will converted to volume and then fetched back at the end.

I guess most suffer programs will be Realflow and Flux. Cos they did similar work and can’t provide any service except dynamics.

#42

again we are just guessing here , but from my limited POV if AD want to give a workflow as flexible and powerful as H , i think externalizing is the best choice. I would never trust an ICE into maya stuff , having encounter so much trouble with nParticles in the past (especially with cache data). i would never trust such ambitious ( don quichotesque ? :slight_smile: ) task …

But i do trust the skill of Marcus Nordenstam … :slight_smile: if they give him the full power to come with his own solution.

#43

Marcus Nordenstam confirmed that it would be independent system that not known what Maya is.

http://www.maxunderground.com/archives/19385_autodesk_siggraph_event_news___including_future_of_naiad.html

#44

Many thanks for that link, Igor. That post clears many things up nicely. :slight_smile:

     Cheers!
     
    PS: For a quick read of the relevant post for people here, I'm taking the liberty to do a copy-paster below.
 
 PPS: Igor, I think this should probably be in your above post, so if you want to include it now "in post", let me know and I'll remove this C&P.
 
    
     "by Marcus Nordenstam - July 26, 2013 9:57 pm
     
                                      Hello everyone,
     
      It seems many people are arriving at incorrect conclusions in regards to Naiad and Bifrost, and how they relate to Maya and Max.
     
      Naiad was a standalone, node-based software that did fluid simulation  (liquids in particular).  You had to use a separate app (Naiad Studio)  to make Naiad graphs, and then export the sim output into Max.
     
      “Project Bifrost” (which is a CODE-name, btw, not necessarily the  actual product name) is also a standalone, more general, node-based  software that will do fluid-simulation – and much more, in time.  
     
      Bifrost does not know about Maya.  There isn’t a single line of code  in Bifrost that directly uses the Maya API.  Maya, on the other hand,   can be made to know about Bifrost.  That’s how we, as a test, integrated  Bifrost into Maya. It follows that Bifrost could easily be integrated  into other DCCs, be made as a standalone product, ported to the iPad –  you name it.  One of the many strengths of the Bifrost architecture lies  in the fact that it’s “product agnostic” and that it can “go anywhere”.
     
      What we showed at the Autodesk User Group last week was the results  of our experimental Maya integration.  We have to focus on one product  and do it right, and the decision was to go with Maya.  I understand  that users of other products such as Max may feel disappointed, but  before you condemn Autdoesk to the 7th circle of hell you should take  note of two things:
     
      1. Autodesk has NOT said that Maya is the only DCC that will ever run  Bifrost.  Just because Maya was chosen does not mean it won’t appear  elsewhere.
     
      2. Even if Maya, in the end, is the only DCC to allow Bifrost FX  authoring, is that really all that different from Naiad Studio?  Nobody  was complaining that you had to use Naiad Studio to author Naiad graphs,  then export the sim output into your favorite DCC, and go from there?   How would this be vastly different?  Maya can, in the worst case, be  viewed as a “better” Naiad Studio.  Use Maya for making your Bifrost FX  graphs – then export the sim results into Max and go from there.  This  is what you did with Naiad Studio + Max, and you can do it with Maya +  Max.
     
      I understand your frustrations, but I wanted to give you guys a bit of perspective :-)
     
      Best wishes,
      Marcus Nordenstam
     
      Any claims that “Bifrost is part of Maya” are false claims "
     
      -  See more at:  [http://www.maxunderground.com/archives/19385_autodesk_siggraph_event_news___including_future_of_naiad.html#commentnum183](http://www.maxunderground.com/archives/19385_autodesk_siggraph_event_news___including_future_of_naiad.html#commentnum183)
#45

Hello, how about Softimage?

#46

What’s that? :wink:

#47

Yes, what about Softimage?

Marcus Nordenstam comparison between Maya and Naiad Studio is a lame excuse to the 10 power.
If Bifrost is agnostic it doesn’t need Maya for anything. Make a Bifrost authoring application that exports everywhere.

#48

Yes you right. It’s business as i wrote before.
If it would be independent app who will update Maya license?
It’s like big plugin to Maya, that’s all. To buy it you need a Maya also as addon:)
I think this what Marcus wan’t to say :wink: