All of these things are basically on the horizon "eventually", depending on need, developer resources, etc.
Houdini-like geometry DOPs are something I want to do for bmesh, but at this point it's hard to tell when that can happen. Shader nodes (real ones, that compile to a real shader language) is also planned, but again no one knows when it'll happen. As for opencl, many of us are excited to start playing around with it :) Joe On Fri, May 7, 2010 at 1:32 PM, nautilus <[email protected]> wrote: > XSI's ICE is the use of a customizable node which can be compared to > the VOP node of Houdini, although ICE is even easier to use than VOP > (which at times can be more complicated). > > Houdini uses a more advanced network of nodes which is integrated > throughout the application, resulting in it being more difficult to > learn and use but ultimately more powerful. Look for example at what > this person has done (it shows the power of Houdini quite well): > http://www.youtube.com/watch?v=jOLhnwllpgs . Houdini is extremely > powerful for things like visual effects and certain types of modelling > (and animation). It's power, because of its advanced node-based > procedural architecture, is still unexplored. It's simulation ablities > are unmatched (only XSI's ICE can come close), and the ability for the > user to make changes with real-time feedback that can only be made > through an advanced node-based procedural method cannot be done > through traditional non-procedural methods or easily done through > unintuitive python scripts. > > Softimage's objective was to create a node-based environment that > would be easier to use than Houdini and for some tasks almost as > powerful. That is why ICE and Houdini are not the same thing, and > should be seen as having different strengths and thus complementing > each other. > > Textual programming was created because of the need to optimize > programming code as well as possible per cpu clock without regards to > readability, given the fact that cpu's were at the time inherently > constrained in terms of performance - python and c look the same and > are mostly the same in regards to intuitiveness. Visual programming is > inherently more intuitive. The use of charts, diagrams, and graphs > combined with some readable text is preferable to raw text. This is > the basis of visual programming, the next step that presents a visual > and interactive environment for the user, something that textual-based > programming could never achieve and which is why is seen as not being > as intuitive by the common user. > > Houdini has been stated many times as being able to save countless > hours of programming by using its well thought-out nodes instead of > textual-based programming (if we take into account the difference > between the amounts of time needed to learn visual and textual-based > programming, and slower than ideal usage of textual-based programming > procedures given the lesser intuitiveness and more complicated nature, > for the common user, of the textual approach). Studios use Houdini > because it is more intuitive and also because in being more intuitive > it is faster to set-up and use. However, Houdini is not exempt from > criticism regarding intuitiveness. These are two good examples that I > have found: > > "POPS, this for me needs a re-write, I'd actually like to see more of > a VOPS style system with multiple inputs/outputs on nodes, I guess > after using VOPS and softimage ICE, this seems like a friendlier way > of constructing a complex particle system." > > "Some attention to VOPs perhaps? > I really believe that VOPs are very powerful, but could we get some > more functionalities as nodes? > I really liked XSI ICE's user friendliness.. Also I kind of liked the > fact that we could create and delete points from within the ICE > network.. Something like this in Houdini could be very helpful (AFAIK > using VEX/VOPs we can't create or delete data inside VOP Networks.. > Please correct me if I'm wrong)" > > ICE is the most intuitive and useful for some tasks. Houdini is used > for when the user needs more control and power. Blender needs to excel > in being able to create 3d animation as easily, as quickly, and as > well as possible by combining non-procedural and procedural workflow > as well as possible. > > This is therefore the next step that Blender needs to take after 2.6 > > 2.6 will be released 2 and half years after it has been announced. 2.8 > can take a similar amount of time. 2.6 was focused on restructuring > and redesigning Blender and making it competitive against all other > packages except Houdini. For 2.8, Blender needs to become competitive > against Houdini by integrating a Houdini-like advanced node-based > all-permeating procedural system (which allows for, and is not limited > to, modelling, animation, rigging, and more), and also integrate a > system like ICE. When this happens, Blender will have finally reached > completion from a theoretical and fundamental point of view. What it > will then be refining will be the integration of non-procedural and > procedural workflow so that 3d animation may be created as easily, > quickly, and as well as possible. > > Blender needs to also be multi-threaded and fully supportive of OpenCL > programming - this will help speed its simulation abilities immensely. > But the most important thing, as always, is to first implement the > main functionalities, and then think about how to optimize and speed > things up. This was posted in one thread that I was reading: > > "The next release is supposed to be a major overhaul of Houdini's > underpinnings, making everything more threadsafe etc. In a fantasy > world, Houdini would have a core scheduler that can schedule across > CPU and GPU cores, and have OPs tell the scheduler what sort of core > they need. A lot of OPs execute a small piece of code a lot of times - > perfect candidates for GPU execution (unified shader model GPUs have > hundreds of "cores"). Also, VEX should be extended to make it possible > to implement most SOPs in it. And VEX should also be comparatively > trivial to port to GPUs using OpenCL and similar APIs. All of this > would not only speed up Houdini, but make it possibly the fastest 3D > environment available, essentially jumping ahead of the rest of the > pack, which sidefx is known for doing traditionally . Also, there is > no reason why POPs aren't multithreaded. They should be > "embarrassingly parallel" in most cases. > > Mantra shaders are a different beast altogether as production level > raytracing isn't feasible on GPU's yet - main memory bandwidth being a > major issue among others. In terms of features, Mantra is missing > irradiance caching, raytraced SSS (for PBR), a mechanism for defining > custom BSDF's, and tone-mapping. IPR should be able to cache rays in a > fine-grained manner for way quicker relighting, and also support > multi-host, essentially bringing it closer to ILM's lightspeed or > Pixar's Lpics. Support for spherical HDRs is one little thing that > would go a long way for many artists. Shader-wise, every exposed input > parameter on a shader should be able to have an input on the shader > node that allows you to connect an exported parameter from another > shader right into it without having to wade through code or VOP orgies > just to add noise as a texture. Basically a mechanism comparable to > co-shaders. Also, finer grained control over PBR bounces per > object/material. Incorporate Mario's IES light into the default ASAD > light. And one ubershader for everyone who just wants to "get there" > 90% of the times without reinventing the wheel. > > DOPs... It's possible to build simpler fluid solvers if you delve into > microsolvers and construct your own, and it will be faster than the > default ones that tend to support EVERYTHING which also slows them > down. How about a few "simpler" fluid solvers out of the box? Also, > one of Houdini's big selling points as a simulation environment is how > integrated everything is, but now we have a lot of special cases where > certain collisions aren't propagated from one type of object to a > certain other - the feeling of confidence that you just set up > something and press play and it will somehow react as expected is gone > to a certain extent. And how about having Hqueue run in "realtime"? > you press play and your sim is calculated across the network. Somewhat > like multihost Mantra." > > -nautilus > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
