[Bf-committers] The final step that Blender needs to take in order to become fundamentally perfect

[joe]

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 <nautilus981 at googlemail.com> 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
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>