[Bf-committers] bridging faces algorithm

[Raul Fernandez]

Hi guys :)

I have being trying without much success to search for an algorithm to perform 
bridging between vertices rings... I have heard about a modified Bresenham 
rasterizer to perform this O.o but I cant find any resource regarding this...
did you have a clue?
Thanks in advance.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] bridging faces algorithm

[Raul Fernandez]

Oh yes thanks, I saw it and is quite powerful, but I'm trying to learn the 
theory behind it, the language independent code...
Cheers




De: Peter K.H. Gragert 
Para: Raul Fernandez ; bf-blender developers 

Enviado: miércoles 7 de septiembre de 2011 17:58
Asunto: Re: [Bf-committers] bridging faces algorithm


Look at the looptool: Bridge!


2011/9/7 Raul Fernandez 

Hi guys :)
>
>I have being trying without much success to search for an algorithm to perform 
>bridging between vertices rings... I have heard about a modified Bresenham 
>rasterizer to perform this O.o but I cant find any resource regarding this...
>did you have a clue?
>Thanks in advance.
>___
>Bf-committers mailing list
>Bf-committers@blender.org
>http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] bridging faces algorithm

[Raul Fernandez]

Thanks a lot! yes, also convex hull algorithm may work too ;)
Cheers!!!




De: Sergey Kurdakov 
Para: Raul Fernandez ; bf-blender developers 

Enviado: miércoles 7 de septiembre de 2011 19:15
Asunto: [Bf-committers] bridging faces algorithm


Hi Raul,

I think, that general algorithm like constrained delaunay triangulation will 
fit - because what is needed -to have a mesh to fit into
boundary points between two rings and it is what constrained delaunay will do,

so docs from http://gts.sourceforge.net/ 

or docs at  http://tetgen.berlios.de/ for 
http://tetgen.berlios.de/features.html#F3

might be of help.

Regards
Sergey
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] bridging faces algorithm

[Raul Fernandez]

Thanks Bart, is suspected it was not universally applied but is a nice 
implementation though ;)



De: bartius crouch 
Para: bf-blender developers 
Enviado: miércoles 7 de septiembre de 2011 21:01
Asunto: Re: [Bf-committers] bridging faces algorithm

On Wed, Sep 7, 2011 at 4:58 PM, Peter K.H. Gragert  
wrote:
> Look at the looptool: Bridge!

That's probably not a very good idea, as I mainly tweaked the bridging
to give proper results with often used situations. There isn't any
real algorithm behind it, only some nonlinear least squares methods.

Bart
(coder of LoopTools: Bridge)
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] bridging faces algorithm

[Raul Fernandez]

Thanks Bart, I suspected it was not a general solution but is still a very nice 
implementation, Cheers



De: bartius crouch 
Para: bf-blender developers 
Enviado: miércoles 7 de septiembre de 2011 21:01
Asunto: Re: [Bf-committers] bridging faces algorithm

On Wed, Sep 7, 2011 at 4:58 PM, Peter K.H. Gragert  wrote:
> Look at the looptool: Bridge!

That's probably not a very good idea, as I mainly tweaked the bridging
to give proper results with often used situations. There isn't any
real algorithm behind it, only some nonlinear least squares methods.

Bart
(coder of LoopTools: Bridge)
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender developers IRC meeting notes, 18 september 2011

[Raul Fernandez]

Just a feature difference: - merging unconnected geometry, but no fundamental 
difference :P
Cheers




De: pete larabell 
Para: bf-blender developers 
Enviado: jueves 22 de septiembre de 2011 17:42
Asunto: Re: [Bf-committers] Blender developers IRC meeting notes, 18 september 
2011

How much different is this than U.C. from Farthsary?

> -Nicholas Bishop is working on "Sculpting Meshes with Self-Adaptive
> Topology" http://liris.cnrs.fr/publis/?id=5105
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] From Farsthary :)

[Raul Fernandez]

@Nicholas

I saw with great pleasure your recent development on Dynamic Sculpting, as my 
lack of free time was preventing me to fulfill my promises with the Blender 
community that have helped me so much in the past and I never forget that, so I 
have being carrying with a conscience burden every day for not finishing 
Unlimited Clay. What I want to propose you is, if you agree, I can help you 
integrating UnlimitedClay features, since you have done most of the part that 
was limiting it (handling a dynamic PBVH). of course, I know you are more than 
capable to get there on your own (you know? when I started the UC project I was 
never thinking in getting it so far, all I wanted to do was to show a good 
technical demo to attract your interest as the main Sculpting dev so it would 
be integrated in Blender successfully as previously I got a great help from 
Matt Ebb and Jahka for the other projects that started also as technical demos 
:P ) and I even think it would not be
 necessary because from your current implementation it would be relatively 
"easy" to add dynamic detail like in UC, with all the respect the author 
deserves I consider the "constant edge length" in the Freestyle implementation 
an artificial limitation rather than a fundamental limitation of the algorithm, 
In LC I could easily fit the dynamic topology with the dynamic subdivision to 
any level without any problem because it was not a fundamental requirement of 
the dynamic topology algorithm. And I agree that the main limitation can be now 
the lack of neighborhood information in current Blender mesh data structure, 
that's why I have put my hopes on Bmesh in the past.

Please feel free to contact me at any time :)
Cheers
Raul
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Dynamic subdivision sculpting (Unlimited Clay) paper

[Raul Fernandez]

Hi guys

Some time since my last invite to my blog, I have uploaded there a paper I was 
working few month ago for SIGGRAPH 2011 regarding UnlimitedClay, it explains 
few interesting things if you want to deepen in it 
I hope this small contribution will be of some value, especially for you 
Nicholas :)


http://farsthary.wordpress.com/
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Cycles movement blur

[Raul Fernandez]

Is interesting a full unbiased solution to motion blur can be instead or 
sampling (rendering) a point in time scene (static) to fully sample(in a random 
or pseudo random) way an interval scene (like the aperture size of the camera)
though this may be more efficient in terms of  required samples it can be 
costly in terms of memory because you have to have simultaneous access to a 
range of scenes instead of one, I don't know how Cycles engine deal with memory 
and frame scenes tough ... those are my two cents ;)




De: Knapp 
Para: bf-blender developers 
Enviado: martes 15 de noviembre de 2011 22:46
Asunto: [Bf-committers] Cycles movement blur

I was just thinking today that Cycles could do motion blur without
taking a big CPU hit. I don't know much about all this so I bet my
ideas is wrong or old but I thought I would post it just in case.

When we do animation the computer calculates tweens and moves stuff
for us. It does this once per frame. Cycles does many render cycles
per frame. It struck me today that if at each cycle pass you move the
object you would get a blur effect. I was also thinking that you might
move it every 100 out of a 1000 pass to get interesting stutter
effects. I look forward to hearing if  my idea was good or only trash.
BTW I would love to see a pause on the main render. Cycles eat my CPU
alive and does not let me do much in the background. A nice/slow
button might be good too but I am sure I am not the first to say this.

Thanks for all the really cool work!! I love cycles, dynamic paint,
motion tracking and ocean sim! All the other stuff is more in the
background but I am sure I will be loving it too once I find it!

-- 
Douglas E Knapp

Creative Commons Film Group, Helping people make open source movies
with open source software!
http://douglas.bespin.org/CommonsFilmGroup/phpBB3/index.php

Massage in Gelsenkirchen-Buer:
http://douglas.bespin.org/tcm/ztab1.htm
Please link to me and trade links with me!

Open Source Sci-Fi mmoRPG Game project.
http://sf-journey-creations.wikispot.org/Front_Page
http://code.google.com/p/perspectiveproject/
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Surface from particles (Farsthary)

[Raul Fernandez Hernandez]

Hi all :)

 I have started to implement the surface generator from the particles,
currently I'm on early stages and I get pretty crude and slow results,
but is working :) There's a lot of things that I need to investigate also
so will be very wellcome papers and resources.(for example fast surfacing
methods, etc.) since for particle methods there's no much public aviable
information (at last for me).

  I also need to learn more OpenGL and how it works with Blender methods,
for example:
  what is the best/fastest way to display an array of triangles?

  I think Blender uses displist? but how does they works?

  what I'm doing rigth now is iterating over the triangle list and draw
each one...

This is a valuable skill when I tackle Voxel Sculpting again since that
part will be central to the voxel scuplting method.

As soon as I get better results I will post them :)

 Cheers   Raul



___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] flame density sampling problem

[Raul Fernandez Hernandez]

Hi :)

> Hello again,
>
> I made some significant progress with the fire simulation system i
> announced here earlier, thanks to the help of jahka, who convinced me
> to integrate this into the particle system. Particles now form the
> basis of the fire's flames, so we can uses them to further simulate
> fire spread and other effects at a later time. See these videos for a
> small impression of how this simulation works:
> http://www.vimeo.com/album/166313
>

 Congratulations for your fast development rate :)

> Now, in order to turn this physical simulation into actual images of
> fire, i started work on the second big part of this fire system, which
> is rendering. Since fire is essentially a fluid, a volumetric
> rendering approach is a natural choice. So my first attempt to render
> the flames was to use a point density texture, which describes the
> flame density, emission and color from the underlying filament data
> (those curves you see in the videos) and an associated density and
> turbulence function. However, after a little test implementation and
> after wrapping my head around how the creators of the original method
> actually did this, i figured that this is not a good approach, last
> but not least because rendering times get _way_ too big (here's the
> original paper again:
> http://reference.kfupm.edu.sa/content/s/t/structural_modeling_of_flames_for_a_prod_96921.pdf).
>

 Well, rendering times could get longer but is not so bad approach, I
think whatever method you came up , still a volumetric rendering option
should be provided. Maya flame effects are very beautifull and are done
with volumetric rendring , if you need further help on this feel free to
contact me at ra...@info.upr.edu.cu.

> So now i need some help to figure out how this could be done with
> Blender's current rendering methods. I need to get a little deeper
> into the math here:
>
> The problem is that directly evaluating the flame
> density/illumination/etc. at a point in space is difficult, because of
> two turbulence functions applied to the raw density function:
>
> 1. Let x be a point relative to a flame filament
> 2. The density/color/etc. at this _untransformed_ point x is then
> given by a function d(x)
> 3. The point x is then transformed by a turbulence function T to a
> point x' = T(x). This simulates turbulence of the surrounding air as
> well as fluctuation of the combustion process and is essential for
> realistic fire!
> 4. In order to determine the actual density at an arbitrary sample
> point s in space (which is what we need to do for volumetric
> rendering), we'd have to calculate d( T_inv( s ) ), where T_inv is the
> inverse of T, which is afaik not easily calculatable ...

 Pardon my ignorance in flame physics but since T is a turbulence function
its inverse should also be a Turbulence function, and while for the
simulation step you need some level of accuracy, for rendering some
tradeoffs could be made, why not trying to render d( T( s ) )? , that
means using the same turbulence function? could be a non sense, but you
could try it ;)

> The solution chosen by the authors of said paper is to generate a
> complete set of point samples for the rendered flame volume in advance
> and then transform these points all together. This creates a new set
> of sample points, which is still sufficiently sampled due to the
> coherence of the turbulence function. This however is more
> complicated, since i'd have to influence the way samples for the
> volumetric material are generated instead of just creating a new
> texture method.

  My first implementation of volumetrics (the discarded path) have the
flexibility to easily allow this, custom tailored sampling
transformations in the volumetric sampling space, though at that time I
thougth  It never will be needed :)
 but the current implementation is more hardcoded/integrated to not allow
this because is more oriented toward physical ligth behavior (ease of
use, intitive) while the first volumetric code where oriented toward
visualization (flexible, harder to use).
  For example a lost feature from the swap of volumetric implemenation was
the adaptive sampling, which allowed more samples on high detail zones
and fewer samples on uniform zones.

  But those are features that we can live without :) , more importantly is
that another approaches should exist.

>I also thought about simply assuming that, due to the
> random nature of noise, the inverse transformation essentially looks
> similar to the transformation itself, so one could just perturb the
> samples before calculating the density, but i guess this would still
> look odd.

 wow! i should have read the whole message before answer you :) , this is
basically what i proposed before .


> I am really just starting to get into the raytracing matter, so i
> might just have overlooked a simple solution to this problem. Maybe
> there actually _is_ an inverse to the turbulence transformation and i
> didn't get it?
> A

Re: [Bf-committers] Surface from particles (Farsthary)

[Raul Fernandez Hernandez]

Hi :)

  Thanks for the very fast repply !

@LetterRip
 Yes, I'm using a marching cubes algorithm and also have implemented the
marching tetraedrom wich I have tested also , and while generate more
precise surfaces is also slower, so i guess it could be left as a quality
option for the user :)


> In general the fastest way to draw an array of triangles in OpenGL is
> with a VBO (vertex buffer object.) You can find examples of how to do
> this in source/blender/gpu/intern/gpu_buffers.c. (I think the VBO code
> was merged maybe two or three months ago? So your sources would need
> to be at least that recent in order to see the VBO code there.)
>
> The basic idea is that you set set up a buffer to hold your vertices
> (including at least vertex coordinates, plus optional normal and color
> data) using glGenBuffers and glBufferData, then set up a separate
> buffer object to hold the vertex indices that make up each triangle.
> Then you can draw using glDrawElements. (Buffer objects are pretty
> flexible, so you have a lot of control over how you split up your data
> into different VBOs; for example you don't have to use an index buffer
> object if you didn't have a lot of vertices used by multiple
> triangles.)

@Nicolas
 I will try it starting tonigth, seems a powerfull solution, thanks :)





___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Surface particles update

[Raul Fernandez Hernandez]

Hi everyone :)

  Thanks to all for the suggested resources , they where of great help

  I'm progressing a lot in the surfacing , I have implemented a spatial
hash structure for boundless marching cubes acceleration that is working
ok

should I implement it as a new BLI_hash file or just inside the
isosurface.c files?

  For the isosurface evaluation I still have to investigate few more
approaches since I'm getting only surface slides of the fluid stream
currently.

  Currently I have a lack of updates in my site because the college net is
nearly collapse due to the VILSEL and several viruses of the same family
that keep the network saturated :(
  KAV and NOD made very little for it, any effecyive solution ?

Cheers Raul

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Particle surfaces update

[Raul Fernandez Hernandez]

Hi all

Last nigth I have finishing implementing the surface refinement for
particles, this allow to increase the resolution of the mesh for smoother
surfaces. I still need to redefine my current surface evaluation from
particles because I´m getting the wrong isosurfaces  but still I could
show you my progress.

I'm very exited about it because I'm learning the necesary skills to
tackle later Voxel Sculpting since are based on the same technologies :)
Is not a beatufl pictures and for end users this may still tell noting but
a month ago I only could dream about achiving this:

 http://farsthary.wordpress.com

 the longest journey start with a step ;)

 Cheers  Farsthary

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Particles surface core is done :) !!!!

[Raul Fernandez Hernandez]

Hi everyone :)

 After a sleepless nigth I have finally fully implemented the particle
surface generator core :)
  Many improvements and optimizations are remaining but the hard part is
done , the fun starts now :)

 though is still heavily unoptimized it still performs at the same level
of instanced metaballs.

   many things remain like the complete OpenGL visualization set using the
VBO and stuffs like that that I need to research (currently is still
using OpenGl inmediate mode for drawing) and implementing color
blending among particles for the polygon mesh.

  Also i would like to implement a caching system like Elbeem (could be
resued here?) for baking the simulation without need to recalculate the
implicit surfaces like the current Metaball implementations do.

   probably I will need help on this

 I have updated my site:

  http://farsthary.wordpress.com

 hope you like this feature

PS: i have tested it with boids also and works ok ;)

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Particles surface core is done :) !!!!

[Raul Fernandez Hernandez]

Ops!


>   Also i would like to implement a caching system like Elbeem (could be
> resued here?) for baking the simulation without need to recalculate the
> implicit surfaces like the current Metaball implementations do.

  I mean "reused" not "resued" :)
  I guess "resued" could mean a dangerous word in english if ever exist
such a word, LOL

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Particles surfacing speed boost :)

[Raul Fernandez Hernandez]

Hi all :)

 I have improved the particles surfacing algorithm and now it has a speed
boost over my previos implementation of an order of magnitude , and is
now near production ready, all of that without multithreading/OpenGL
optimizations :P , so in the future there's lot of room for further speed
gains.

  check my site:
  http://farsthary.wordpres.com

   hope you like it

  Cheers  Farsthary




___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Particle surface reconstruction (Farsthary)

[Raul Fernandez Hernandez]

Hi again

 when I started this project Erwin wrote:

> We recently got a contribution of real-time SPH for Bullet, without
> the rendering, so if you come up with some good implementation under
> the ZLib license, we could use that within the BGE.
>
> (this SPH implementation is both for CPU and CUDA/GPU, done by Rama
> Hoetzlein, see http://www.rchoetzlein.com/eng/graphics/fluids.htm )
>
> Good luck,
> Erwin

 And now that I'm close to reach production levels how should I release it
to be compatible with Blender and Bullet?

  Thanks in advance

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Particle surface reconstruction (Farsthary)

[Raul Fernandez Hernandez]

Hi Erwin :)

> Hi Farsthary,
>
> So you implemented some iso-surface generation for SPH particles?

 Yes, I have progressed a lot from my first attempts :)

> Sorry I've been busy with trying to get Bullet 2.76 out of the door (still
> more work),
> but I'm interested in your work.
>

  Thanks a lot! though I'm orders of magnitude more impressed for your
work in Bullet.


> Do you consider making it available under the ZLib license?
> Thanks
> Erwin

   Seems a good option, that way could be reused/modified in Bullet and in
Blender. I still need to improve and polish more the code but I'm
getting closer :)

> By the way: have you tried to integrate it into the Bullet SPH
> implementation by Hoetzlein (from the Bullet/Extras/sph folder)?

  I haven't look at bullet source code but i definatelly should dive into
it as this project approach to its first iteration.

 I will first release the SPH engine for Blender particles and later the
isosurfacing generator.

   Thanks!
Raul

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Particles surfacing speed boost :)

[Raul Fernandez Hernandez]

Hi Aurel :)

> Isn't marching cube very trivial to parallelize?
>

 It should because cell polygonization is independent one from another
but I have no experience in multithread programming in Blender, in what
 feature/files already coded could I look to learn how it is done?

   Thanks in advance  Raul


___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Particle fluids buoyancy... wellcome gases :)

[Raul Fernandez Hernandez]

Hi all :)

 las nigth I have implemented a buoyancy force for particle fluids that
will allow simulation of gas particles, not just liquids that are the
widespread solution, and since those parametters could be animated I
start imagine boiling watter ;)

  visit my site for wispy smoke tests

   http://farsthary.wordpress.com


   Cheers  Raul

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Particle fluids buoyancy... wellcome gases :)

[Raul Fernandez Hernandez]

Hi Lukas :)

   thanks :)

> Have you thought about rendering gases yet? I guess this is a
> different challenge, since you cannot approximate gases by a sharp
> surface boundary (except for very stylized art perhaps). Point density
> texture might be the right answer, but you may have to add additional
> turbulence to get small scale detail. Point density textures already
> support turbulence, not sure if that would be sufficient (afaik the
> current smoke simulator uses a similar technique, using wavelet
> turbulence for small noise frequencies or so. Just wildly guessing
> from my limited knowledge.)

  That's currently the path to render particle gases, you're rigth !

>
> I suppose you used a turbulence modifier on that empty to make those
> particles move "randomly" ? If so, you might be interested in the flow
> noise method i use, here's a small test video used with a volume
> texture: http://vimeo.com/8929215. This could easily be applied to the
> turbulence modifier to avoid the static behaviour (particles
> essentially clumping in the same places all the time). Until now it
> seemed i was the only one actually interested in this, so i didn't
> make a patch yet, but it can be done quickly. I know very little about
> actual fluid simulation, so i don't know if this "fake" turbulence
> could/would be replaced by inherent fluid features.

 yes, those empties contain turbulent fields and your proposal of a better
turbulent field seems very interesting ... so I preciate any
collaboration in that :)


> Just hope your particle simulation is not too efficient, so that there
> might still be a place for my own fire sim ;)
> Keep it up!
>
> Lukas

 Nah ;) , your approach is also very interesting and has potential , the
good thing about Blender is that is a blender of 3D technologies ... a
name never have being better choosen.

  Cheers and keep ut you to.
   Farsthary

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Particle fluids update

[Raul Fernandez Hernandez]

Hi all :)

 I spend the hole weekend squeezing a bit more optimizations for the
surface reconstruction from particles, I have implemented a marching step
only to the surrounding voxels that contains the surface (and not to
every surrounding voxels as before) also I have implemented corner value
reusing (every new step reuse the half of the previous calculated voxel
corner values) and finally I have rewritten my previous spatial hash code
that use integer operations to reuse the metaballs bitwise hash functions
 all of this optimizations are pushing the surface generation to its
limits, further speed up I think will be gained only with multithreading
and or OpenCL but that is out of my current scope/skills.

  As a comparison note, this implementation has outperformed the metaball
instanced particles by a huge margin.

  I probably will spend this week cleaning the code for make a separation
between fluid particle engine and visualization engine and will send
Jahka the first patch for review.

  Once integrated the fluid particles engine the efforts could be focused
on renderable meshings :)

 Cheers  Farsthary

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Particle Fluids engine patch at last! (farsthary)

[Raul Fernandez Hernandez]

Hi all :)

Here's at last the first public patch of the Particle Fluids engine , this
means that still don't have included the particle surfacing because is
still a work in progress but the engine is pretty usefull in its current
state and particles could be rendered via splatting or using pointdensity
for more advanced volumetric particle effects (remember my pouring moss
tests?) and finally you could use instanced particles to whatever you want
, including metaballs, though those are not replacement for the upcomming
particle mesh surface ;)

I have sended the patch to Jahka for his expert review and commit, and
once integrated in its final GUI form Stephen and me could start writting
down documentation of the many features it have.  I have included also two
quick .blend test files to figure out of the settings

PATCH:   http://www.pasteall.org/11232/diff

TEST BLENDS:  http://www.pasteall.org/blend/1959and 
http://www.pasteall.org/blend/1960

  The main actors of this achievements are Stephen, Jahka and your
servant: Farsthary


I
will
enjoy
this
part:
Feedback




Cheers
to
all
and
THANKS!

PS: in the future the engine may change a bit because I'm researching ways
to speed up simulations by data structures other than the kdtree it
currently use ;)



___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Bugfixed Particle fluids patch

[Raul Fernandez Hernandez]

Hi all :)

 thanks to community feedback I have solved an initialization bug in the
particle fluids code, here's the updated patch:


http://www.pasteall.org/11270/diff

is important to test this feature now before Jahka start reviewing and
committing it. I provide test files in my site:

 http://farsthary.wordpress.com

 thanks in advance,  Farsthary

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] I'd like to kill the soft body module

[Raul Fernandez Hernandez]

Hi all :|

> Hi all,
> I've been watching 2.5 evolving and I feel the (one size fits all ..
> experimental physics code) soft body module has been replaced by the far
> better cloth module at the hot spots. ( Thanks will go to janne and daniel
> )

 Is good that one module function overlaps another module function, that
speaks about how powerfull blender has became, but if they're well
designed there will be always use cases optimized for Softbodies and
clothes, furthermore, even if is not the case currently and softbodies
may seems unmaintained, in the future other interested devs could take
advantage of it an resume its development and improve it.


> Further I think that future development ( in Blender ) should focus on
> visual effects rather than try to simulate real world physics (which is
> 'in given range' mission impossible ) .

  And what are visual effects without physically based simulations? 
faking effects are clever, perform fast and several pros but always will
miss something that only could be achieved with physically based
simulations and are difficult to make.
  I don't think making Blender a "you-must-build-and-fake-everything" will
be a good option.
 One thing is physically accuracy (that we should avoid because its price
is speed) and other is visual realism.
  I do think that physics simulations (ranging from rendering (physically
based ligth behavior) to cloth, particles, character animation) have a
brigth future in Blender and will make a difference because they bring
realism to the masses.


> So I'd like to kindly ask for the permission to remove  that  wrong view
> angled, physicists, crappy code.
> BM

 I would like not to remove it , just in case it makes more harm than
good,  is sad to drop countless man/hours, efforts and knowledge, but I
guess is just me and is only my personal choice.

cheers  Farsthary


___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Particle fluids status

[Raul Fernandez Hernandez]

Hi all :)

  Just a quick update:
  I'm working with Jahka refining the final patch, thanks to its feedback abd
  the users feedback I will modify several things in the final patch, like
default values and remove some small things that are in future particle
system design roadmap.
   Next week when Blendiac and WhifeofBlendiac return home they will upload
  several very interesting high resolution screencasts I have made on some
use cases of particle fluids.

  Including a very interesting one using particle fluids to simulate sand
  (high number of small solid points that interact with its closest
neighbours) of 100k particles, at near 1 fps simulation.

   Cheers to all
 Farsthary


___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Unified physic simulation (Lagrangian)

[Raul Fernandez Hernandez]

Hi Thomas :)

  Thanks for the links! I will review it as soon as I get connected again.

  the SPH implementation is quite powerfull and easy to extend, hopefully
Blender will have soon an SPH framework.


Cheers  Farsthary

> Sorry I forgot the link to the animations:
> http://www2.cs.kuleuven.be/~graphics/publications/LenaertsPhD/animations.php
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>


___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Particle Fluids Engine corrected patch

[Raul Fernandez Hernandez]

Hi all :)

Thanks to Jahka review and advices I have corrected the particle fluids
patch and have simplify it for better integration. Also I have discovered
and solved an important bug in the multi-fluids interaction that cause
strange behavior in fluids.

here you will find the new patch:

http://www.pasteall.org/11805/diff

and here a new test blend:

http://www.pasteall.org/blend/2223

The short list of changes are:

Important multifluids bugfix, better defaults and parameter naming and a
cleaner patch.

I have temporarily removed the particle color and temperature
visualization since are targeted for future design in Jahka framework, but
once committed the code will be easy to add back.

I will soon upload a pdf with all the features of particle fluids.
Once committed I will focus back on the surface creation over a fresh SVN
oficial build ;)

   Cheers  Farsthary


___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Blender security paranoia

[Raul Fernandez Hernandez]

Hi all :)

WARNING: this email is not targeted to anybody in particular, is just my
opinion and I like to learn from my mistakes :)

I think is good to think in all threat possibilities that could arise in
the future but I really don't understand all the paranoia that has being
awaken toward Blender.
  It makes more harm than good because it introduce the fear in the
Blender ecuation , the user that will make .blend content that is worth
downloading and sharing will not burn his hard earned reputation in
making scripts for stealing user information or deleting user files.
 C'mon we are 3D guys working hard for making  well, you guess, 3D ,
is very different from people killing time writing trash on Word or
Power-points and also from a malicious developer point of view the user
share of Blender (and really from any 3D app) is not worth it.
  In all the blender history mention a case when something like that have
happened before.
 And while that is not a strong argument that prevent such situations from
happening in the future I think such level of security is an SO duty, not
an app task.
  Blender could not live without python and making mechanisms for avoid
automatic and hiding script running is OK, but I think we should not
take that further.

Regards farsthary



___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Particle fluids videos uploaded

[Raul Fernandez Hernandez]

Hi all :)

 Thanks to Blendiac aid now there`s several particle fluids video
tutorials uploaded.
  Though things has changed from the time I record those videos, the
workflow and remain very similar and from watching it users could grasp
how is working with particle fluids.

 I also provide a video of how to render them as volumetric point density
particles and some sand simulations.

 visit my site for more details:
  http://farsthary.wordpress.com

   hope you like them.
   regards Farsthary

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Volumetrics for cartoon shading? and fluid particle status

[Raul Fernandez Hernandez]

Hi all

   Did someone have found something similar before on volumetrics?
  Tinkering with volumetric solids I have found that could be used for
cartoon shading also.

  check my site for more details:

   http://farsthary.wordpress.com

 Regarding fluid particle status Jahka has given an incredible helpful
feedback and contributions and also green light for integration, I'm just
waiting for him to commit to resume the surfacing work, plus some other
acceleration techniques I plan to apply.

Cheers  Farsthary

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] version naming

[Raul Fernandez Hernandez]

Hi :)

 +1 Agree, for non devs talking in decimal terms diminish the wow factor ;)
  so 2.49, 2.50, 2.51 , etc hide the huge change Blender have experienced.
  Is better a versioning system that reflect the magnitude of changes:

   Major Version . Minor Version . Bugfixes

  Major Version represent a core revamp/refactor, (like from 2.49 - 2.5)
so is better from 2 to 3

   Minor Version represent new "big" features added and Bugfixes represent
, well, exactly that and alo minor features and tweaks

   The problem of using whole numbers from one version to another is that
with the development rate of Blender we will reach very quickly the
Maya/Max (in gradual revamp process also) and C4D ;)

  Cheers   Farsthary




___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] From Farsthary moving colliders patch

[Raul Fernandez Hernandez]

Hi Janne :)

  Starting the documentation I have exhaustive tried the commit and have
found several issues, hopefully I have the solution for two or the three
problems I have found.

   First the moving fluid emitter:
when you play a fluid sim and start moving emitter particle fluids
inherit the moving emitter speed which is not a desired feature. I was
suspecting it was due to some relative velocity therm and I was rigth
, here's the patch (is fairly simple, just a line of code):

//-

Index: source/blender/blenkernel/intern/particle_system.c
===
--- source/blender/blenkernel/intern/particle_system.c  (revision 28047)
+++ source/blender/blenkernel/intern/particle_system.c  (working copy)
@@ -2308,8 +2308,7 @@
VECCOPY(start, pa->prev_state.co);
VECCOPY(end, pa->state.co);

-   sub_v3_v3v3(v, end, start);
-   mul_v3_fl(v, 1.f/dtime);
+   VECCOPY(v, pa->state.vel);

neighbours = BLI_kdtree_range_search(tree, radius, start, NULL, &ptn);


//-

While the previous approach aparently is more stable, when the user move
the emitter, the difference between end and start position, quickly jump
and is no longer a measure of the particle initial velocity. Moreover,
that older approach ignore completely the particle speed Damp factor, you
could change it and nothing happens, that is the second issue that is now
solved with the new approach.

And the more anoying issue is regarding the random particle explosions
that happen with colliders. Tracking down the issues I have found that it
has nothing to do with the SPH because it worked perfectly with older
revisions, and seems to be due to recent changes that have being commited
to the particle mesh colliders code ... what where those changes?
  That is a special problematic issue because it is prevempting from
propper collissions and fill containers because everything explodes.


___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Patch to SPH particles moving emitter issue

[Raul Fernandez Hernandez]

Hi all :)

  When you play a fluid sim and start moving the emitter, particle fluids
inherit the moving emitter speed which is not a desired feature and a
second bug caused from the previous code was the ignore of the absolute
particle velocity Damp factor.
 Here's the patch (is fairly simple, just a line of code):

//-

Index: source/blender/blenkernel/intern/particle_system.c
===
--- source/blender/blenkernel/intern/particle_system.c  (revision 28047)
+++ source/blender/blenkernel/intern/particle_system.c  (working copy)
@@ -2308,8 +2308,7 @@
VECCOPY(start, pa->prev_state.co);
VECCOPY(end, pa->state.co);

-   sub_v3_v3v3(v, end, start);
-   mul_v3_fl(v, 1.f/dtime);
+   VECCOPY(v, pa->state.vel);

neighbours = BLI_kdtree_range_search(tree, radius, start, NULL, &ptn);


//-

While the previous approach aparently is more stable, when the user move
the emitter, the difference between end and start position, quickly jump
and is no longer a measure of the particle initial velocity moreover, that
older approach ignore completely the particle speed Damp factor, you could
change it and nothing happens, that is the second issue that is now solved
with the new approach.

   The random particle explossions issue is something we are working on,
it dosen't happen in older builds (27326 and olders)

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Small apologize

[Raul Fernandez Hernandez]

The first email was intended for Jahka only and the second for the list, 
by accident I sended both at the same email :(

   I apologize for that and sorry
for triple posting.
Regards Farsthary

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Sub frame calculations for particle systems done!

[Raul Fernandez Hernandez]

Hi all :)

  Stability is one of the most desired feature of a simulation and in
particle systems is a must have. The particle fluids exhibit random
explosions (which I think could be reduced because in older SVN
revisions that doesn't happen) and in general the particle systems have
a leaking trough wall containers behavior when the container rotates.
(think of the typical wine glass falling example :) )
  As a suggestion from Jahka and several members of the community I have
implemented particle subframe simulations not just for particle fluids
but for the whole particle system.

  Subframe simulations greatly increase the stability of the simulation to
any desired level, it basically perform a user defined number of
pre-simulations in between frames, allowing finer grain sims, and a nice
side effect of it is that now particle-surface collisions could be
properly captured so there's no leaking effect when containers rotates.

  Subframe simulations do increase the calculation time proportionally to
the number of sub-steps, so the user have to made a trade-off between
stability and simulation time. But the good news is that there's now a
lot of methods to reach stability in the particle systems so a
combination of them will help to get very low substeps (even none) to
get stable simulations and proper particle collision detection very
fast.

I have recorded several videos of the feature in action, and as soon as I
get connected today I plan to upload and publish the patch.

 Regards Farsthary

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Sub frame calculations for particle systems done!

[Raul Fernandez Hernandez]

Videos are now uploaded, check my site
http://farsthary.wordpress.com

and here is the patch:
http://www.pasteall.org/12304/diff

 cheers  Farsthary

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Sub frame calculations for particle systems done!

[Raul Fernandez Hernandez]

>
> Raul,
>
> The videos are set to private.
>
> -Sean
>

Ops! sorry, I have changed to public, hope it works now!
  Thanks!

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Improved Group restriction patch (previous Group as layer patch)

[Raul Fernandez Hernandez]

Hi all :)

 Some time ago I have coded a group aslayer patch that suffer from several
small drawbacks, mainly in the GUI part and not in the conceptual
level. Also I must confess that my previous patch was awfull to review and
apply :P
  So I take some time to rewrite it from scratch and improve it a little.
Now is much more functional and easy to apply/integrate than before!

  This patch basically add the posibility to toggle visualization,
selectability (freezing to avoid accidental modifications) and
renderability of entire groups of objects , replicating the functionality
of a layer manager because groups could be already renamed and managed
in ways that a layer manager could not do (but the main target is not a re
layer manager, just another usefull tool for huge and complex scene
management), that´s why I called it Groups as Layers patch before, it
extend the functionality of groups in the outliner in a
natural and very needed way:

  If you want to be able to arrange your objects in logic ways, for
example, the most basic realistic mechanic modeling could have hundreds
of parts,
then 20 layers is not enough, you want a layer named bolts, other named
gears, and many more that soon will pass the 20 limit ;)

 In my site I have upload some videos showing it in action in basic scenes
  I hope you like and will be very pleased to receive some
reviews/opinions about it, and I hope with this second attempt we have a
winner

   Cheers   Farsthary


___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] "Security" gets in the way

[Raul Fernandez Hernandez]

I hope I'm wrong and is something I have missed from the "Security"
discussion but is leading to dangerous thougths Dropping python?!?!?!

Python support has being one of the best steps Blender has ever made, even
before the industry standard packages start considering python (when each
one implement their own scripting language leading to a migration chaos
among them)
 I think dropping python is not an option, is a suicide ;) and is
definatelly more harming than all the possible threats that is suppose to
solve.

-1 ad infinitum :)




___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] "Security" gets in the way

[Raul Fernandez Hernandez]

Is time to end up this security discussion: paperware is very beautiful
but never leave the planification phase.
  The pro-security team could work on a prototype that could shut up the
rest of us that think this discussion is getting in the way, meanwhile,
the rest of us could continue improving blender.

regards  farsthary

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] "Security" gets in the way

[Raul Fernandez Hernandez]

> Raul Fernandez Hernandez wrote:
>> Is time to end up this security discussion: paperware is very beautiful
>> but never leave the planification phase.
>>   The pro-security team could work on a prototype that could shut up the
>> rest of us that think this discussion is getting in the way, meanwhile,
>> the rest of us could continue improving blender.
>
> Are you speaking for the Blender development team or just yourself?
> Serious question as I'd like to know if the opinion that adding security
> is not part of "improving Blender" is shared at the top level. After
> all, if Ton (for example) doesn't want there to be a security option -
> there simply isn't going to be one as it will never get into trunk.
>
> There is no point makling a prototype if the end-result is already
> predetermined as "we don't want it".

 Don't get me wrong, I have no intention of discrimination , I think the
fact that english is not my way of thinking could lead to this. I was
speaking for myself , splitting in pro-security and the rest is very
natural when a discussion arise, is nothing bad,  and when I was
referring to "the rest of us could continue improving blender" I didn't
mean that working in security was not improving blender, I mean: "the
rest of us could continue working in their projects in blender".
  I think a working patch or prototype is way better than a long
discussion that sometimes get out of its path, nothing more.

 Cheers  Farsthary



___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Spatial hashing

[Raul Fernandez Hernandez]

Hi all

  I'm currently developing/researching a spatial hashing structure as an
alternative to the particles kdtree, hashing has several advantages over
hieraquical data structures like trees like O(1) insertion, and linear
worst case queries (and other drawbacks) that's why I'm  investigating
if there are performance gains under high particle numbers (where
hashing shows advantages over trees)

  I preciate if anyone could suggest me good resources on spatial hash
integer functions, and a way to measure the exact calculation time in
order to compare both algorithms

  Cheers   Farsthary

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

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

[Raul Fernandez Hernandez]

Hi there

> I know resources are limited but what is to stop a few from starting a
> branch and exploring this very interesting area? I could see it as
> being a nodal extension of the game engine. I do admit to knowing very
> little about this subject but that is what it looked like in that
> SUPER cool video.

 You cannot fork Blender for a "huge" revamp in its current state, when
haven't finished the previous revamp because then the sync back could
become near impossible, you could base your entire codebase in things
that simply will change or could dissapear in the official branch. Only
after few stable releases you could fork Blender for a major architecture
change like this.




___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Spatial hashing

[Raul Fernandez Hernandez]

Hi :)

  Thanks for the links, sadly i could not access googlecode (is part of
the embargo issue) and also the sourceforge issue remain ... I haven't
being able to download a single bit from them.

  Anyway, thanks, I have performed several test and hashing will not
provide much more advantage over the current kdtree because the
performance bottleneck in the particle systems is not in the spatial
structure, I will make a few tests more with the blender BLI_ghash
module (I just have discovered it ;) )

> Google gave me these:
> http://perfecthashing.googlecode.com/files/perfecthash.pdf
> http://code.google.com/p/perfecthashing/
>
> I admire your work Raul.
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>


___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Spatial hashing

[Raul Fernandez Hernandez]

Yes, I have tried Tor but it makes so sloow my already slow connection
that is practically not an option, loading a clean page like google takes
ages, not even think on downloading  :(

Cheers Raul

> Shame on Google.
>
> Have you tried something like Tor:
> http://www.torproject.org/index.html.fr
>
> Maybe it can help.
>
>
> 2010/5/10 Raul Fernandez Hernandez :
>> Hi :)
>>
>>  Thanks for the links, sadly i could not access googlecode (is part of
>> the embargo issue) and also the sourceforge issue remain ... I haven't
>> being able to download a single bit from them.
>>
>>  Anyway, thanks, I have performed several test and hashing will not
>> provide much more advantage over the current kdtree because the
>> performance bottleneck in the particle systems is not in the spatial
>> structure, I will make a few tests more with the blender BLI_ghash
>> module (I just have discovered it ;) )
>>
>>> Google gave me these:
>>> http://perfecthashing.googlecode.com/files/perfecthash.pdf
>>> http://code.google.com/p/perfecthashing/
>>>
>>> I admire your work Raul.
>>> ___
>>> Bf-committers mailing list
>>> Bf-committers@blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>
>>
>>
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>


___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Compiling Blender on CodeBlocks/MinGW

[Raul Fernandez Hernandez]

Hi

 I generate the Makefiles and the CodeBlocks files with CMake without
problems but when I compile the project in Codeblocks I get this errors



C:/Blender_Build/blenderSVN/intern/ghost/./GHOST_Types.h:45: error:
`__int64' does not name a type
mingw32-make.exe[1]: Leaving directory `C:/Users/Raul/Desktop'
C:/Blender_Build/blenderSVN/intern/ghost/./GHOST_Types.h:46: error:
`__int64' does not name a type
C:/Blender_Build/blenderSVN/intern/ghost/./GHOST_Types.h:438: error:
`GHOST_TUns64' does not name a type
C:/Blender_Build/blenderSVN/intern/ghost/./GHOST_Types.h:439: error:
`GHOST_TUns64' does not name a type
C:/Blender_Build/blenderSVN/intern/ghost/./GHOST_Types.h:443: error:
`GHOST_TUns64' does not name a type
C:/Blender_Build/blenderSVN/intern/ghost/./GHOST_Types.h:444: error:
`GHOST_TUns64' does not name a type
C:/Blender_Build/blenderSVN/intern/ghost/./GHOST_Types.h:492: error:
`GHOST_TUns64' has not been declared
C:/Blender_Build/blenderSVN/intern/ghost/./GHOST_Types.h:492: error: ISO
C++ forbids declaration of `time' with no type
mingw32-make.exe[2]: ***
[intern/ghost/CMakeFiles/bf_ghost.dir/intern/GHOST_Buttons.cpp.obj] Error
1
mingw32-make.exe[1]: *** [intern/ghost/CMakeFiles/bf_ghost.dir/all] Error 2
mingw32-make.exe: *** [all] Error 2
Process terminated with status 2 (0 minutes, 17 seconds)
8 errors, 11 warnings

any help/hint? I'm compiling on Win7 64 bits

  Cheers  Farsthary


___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Dynamic Sculpting Tessellation (Sculptris main feature) in Blender (Farsthary)

[Raul Fernandez Hernandez]

Hi all :)

   Well, this is another code surprise I have prepared for the community ...

 I fell in love with 3D Coat Voxel Sculptig and with Sculptris dynamic
tesselllation on the fly , both approaches , although very different
under the hood tackle the same problem: artistic freedom and unlimited
clay, in both features there's no need to worry for polygon stretching
while you sculpt!

  Some time ago I have contacted the developer of Sculptris hoping for
hints or help to implement that on Blender, sadly he has not the time to
do that.
 but anyway, I like challenges and having in my mind the goal, the path
will be revealed ;)

  But few days ago with the revival of the Sculptris interest I decided to
ush myself a little and at least implement a basic working prototype,
but the results although still is non ready for production and I'm sure
is not optimally implemeted, has surpassed my initial expectations for
the first teration.

 Since Mesh/Sculpting is not my main field rigth now, I would preciate the
further help of experienced devs on this are to make a decent/production
ready implemetation of this very useful tool.

  I have sended to Lapinou a video showing it in action, so he will update
 soon my blog.

 http://farsthary.wordpress.com

  Keep in touch , I'm very excited about it and can't stop playing
with it.

warning: it lacks currently a lot of functionality and is not a Sculptris
competitor, but every plant start as a seed ;)

  Cheers  Farsthary

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Dynamic Sculpting Tessellation (Sculptris main feature) in Blender (Farsthary)

[Raul Fernandez Hernandez]

Hi all

  Lapinou have upload a new video I have send him of dynamic sculpt
tessellation with few improvements.

   http://farsthary.wordpress.com

  I will soon release the code and or integrate this feature in my
experimental branch.

   At that point I will preciate the review and aid of an experience
sculpting dev to take it further.

 Cheers  Farsthary

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] documented creating a custom modifier

[Raul Fernandez Hernandez]

Hello Ian

> Hello all,
>
> I did a quick writeup of my experience creating a custom modifier. It
> doesn't do anything but printf when its added to an object, but hopefully
> this post can prove useful to new devs (such as myself ^_^)
>
> http://enja.org/2010/05/24/blender-creating-a-custom-modifier/
>
> I couldn't find this process documented online. The closest was this
> unfinished tutorial:
> http://wiki.blender.org/index.php/Dev:Doc/How_to/Add_an_Object_Type
>
> I would appreciate any feedback (especially if I'm wrong about something)
> and I would be happy to add this to a wiki or something, I'm just too new
> to
> the community to know where it would go!
> Tomorrow I'm going to try adding some functionality to my modifier, and
> also
> have it affect how the object is rendered in the game engine. Hopefully
> I'm
> on the right track!
>
> --
> Ian Johnson

 This kind of tutorials are of great help for new devs and devs that
covers wide areas of Blender, I think this ind of step by step tutorials
provide a very valuable and easy road to be initiated in development :)

Thanks   Farsthary



___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] a quick question

[Raul Fernandez Hernandez]

Hi all :)

 I'm about to commit to my branch the Unlimited clay feature for
sculpting, but I'm getting troubles trying to set up the default value
for the new property brush.detail, in the RNA the range is 0.05-1.f where
0.05 subdivide a lot the mesh and 1.0 is quite rough so the default vaue
should be 0.25
 but I could not find the place where the brush get its default value

add_brush() only works with newly created brushes, not the ones that exite
when Blender start

 If I get a quick answer I could commit by today

 Thanks in advance   Raul

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] a quick question

[Raul Fernandez Hernandez]

Hi :)

Thanks for the really quick repply ... yes, I think I will commit without
the default value and then an experienced dev could do that, after all is
what open source is about ;)

 The default value of 0.05 is very dangerous because it subdivide a lot
the mesh, so 0.25 is a safer value.
I will start trying to get connected and write some quick information
regarding unlimited clay for users

  Thanks a lot
   Raul

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Unlimited Clay committed

[Raul Fernandez Hernandez]

Hi guys!

 I finally committed the unlimited clay feature to my branch: it have
several design desitions that should be discussed later like the exposing
the mesh tools (though I think are rigth ;) )

 A warning: it dosen't work with multires currently, seems that multires
don't initialize few fields that are needed for unlimited clay and
crashes

A warning: while is not set to a correct default around 0.25 , when
activated, the detail property is set to 0.05, rise up to 0.25!

 And few differences compared with Sculptris:

  Sculptris use a different mesh system and different mesh subdivission
scheme, but that is only the make up, the underlying algorithm is the
same and in the future the blender mesh subdivide tool could and should
be improved, also Bmesh will provide new tools to toy with :)
  all of this is independent to Unlimited Clay because is designed to be
very modular, it simply use existent Blender mesh tools :)

 Currently I have designed to do the subdivision at stroke finish step,
while sculptris perform this step all the way while the stroke is
executing, this is something that could be improved in the future,
another make up difference.

  I hope it will be at least usefull as a seed for a
powerfull feature.

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Unlimited Clay committed

[Raul Fernandez Hernandez]

and here's the patch

http://www.pasteall.org/13481

  Cheers   Raul

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] a quick question

[Raul Fernandez Hernandez]

Hi

 Thanks a lot :), as soon as I get connected I will fix that.


> Changing the default .blend also would not be enough, since existing
> .blend files still wouldn't be converted. Here's the code you can add
> at the end of do_versions in readfile.c.
>
> for (brush= main->brush.first; brush; brush= brush->id.next)
> if(brush->detail == 0.0f)
> brush->detail = 0.25f;
>
> Brecht.
>
> On Mon, May 31, 2010 at 9:58 PM, Diego B  wrote:
>> If it's the default value, before change the default blend, you can
>> try with a do_versions.
>> Change the default blend file always come with problems ;)
>>
>> On Mon, May 31, 2010 at 4:51 PM, Daniel Salazar - 3Developer.com
>>  wrote:
>>> BTW this should be done very carefully, if you want you can just
>>> commit like it is and I will fix the defaults later?
>>>
>>> cheers
>>>
>>> Daniel Salazar
>>> www.3developer.com
>>>
>>>
>>>
>>> On Mon, May 31, 2010 at 1:49 PM, Daniel Salazar - 3Developer.com
>>>  wrote:
>>>> Hi Raul, those are actually saved in the B.blend.c file
>>>> (/blender/source/blender/editors/datafiles and you would need to
>>>> generate a new compilable default blend file using the datatoc.py
>>>> script included in release
>>>>
>>>> pura vida!
>>>>
>>>> Daniel Salazar
>>>> www.3developer.com
>>>>
>>>>
>>>>
>>>> On Mon, May 31, 2010 at 1:45 PM, Raul Fernandez Hernandez
>>>>  wrote:
>>>>> Hi all :)
>>>>>
>>>>>  I'm about to commit to my branch the Unlimited clay feature for
>>>>> sculpting, but I'm getting troubles trying to set up the default
>>>>> value
>>>>> for the new property brush.detail, in the RNA the range is 0.05-1.f
>>>>> where
>>>>> 0.05 subdivide a lot the mesh and 1.0 is quite rough so the default
>>>>> vaue
>>>>> should be 0.25
>>>>>  but I could not find the place where the brush get its default value
>>>>>
>>>>> add_brush() only works with newly created brushes, not the ones that
>>>>> exite
>>>>> when Blender start
>>>>>
>>>>>                     If I get a quick answer I could commit by today
>>>>>
>>>>>                         Thanks in advance   Raul
>>>>>
>>>>> ___
>>>>> Bf-committers mailing list
>>>>> Bf-committers@blender.org
>>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>>>
>>>>
>>> ___
>>> Bf-committers mailing list
>>> Bf-committers@blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>


___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Unlimited Clay committed

[Raul Fernandez Hernandez]

Ops! I didn't know I have to suscribe also to a new mailing list, when I
get online again I will see that :)

Also, devs that find new aditions or good solutions for Unlimited clay are
encouraged to commit to my branch.

   Cheers  Raul

> It seems to be this commit (29110)
> https://projects.blender.org/plugins/scmsvn/viewcvs.php?view=rev&root=bf-blender&revision=29110
>
> 2010/5/31 Daniel Salazar - 3Developer.com :
>> I didn't see the commit on the mailing list :o are you sure you
>> commited to you branch?
>>
>> cheers
>>
>> Daniel Salazar
>> www.3developer.com
>>
>>
>>
>> On Mon, May 31, 2010 at 3:04 PM, Raul Fernandez Hernandez
>>  wrote:
>>>
>>> and here's the patch
>>>
>>> http://www.pasteall.org/13481
>>>
>>>              Cheers   Raul
>>>
>>> ___
>>> Bf-committers mailing list
>>> Bf-committers@blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>


___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Unlimited Clay committed

[Raul Fernandez Hernandez]

Hi

  I have committed the default value fix, thanks! now should be better

 I will try to post today a basic tutorial and explanation on how it works

 Cheers Farsthary

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Unlimited Clay committed

[Raul Fernandez Hernandez]

> There are several places in the code that do not compile with MSVC because
> it does not allow you do declare variables after the beginning of a block.
>
> For example there are many places where EditMesh* is declared.  I'll
> commit
> the code that doesn't compile for me, then after that I'll commit a
> version
> that works with MSVC.
>

Ok, I'm unaware of those restrictions because I compile with gcc in
windows and linux

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Unlimited Clay committed

[Raul Fernandez Hernandez]

Yesterday I have committed a new patch that add a new property to the
unlimited clay: smoothness, that controls the subdivission smoothness

 here's the patch:
 http://www.pasteall.org/13522/diff

 @Letterip: Oh, I will need to apply tose fixes too :)

 Cheers   Farsthary



___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] farsthary-branch small commit

[Raul Fernandez Hernandez]

 properly free the editmesh resources on each creation (should be better
memory wise now)
  and also applied the fix that Letterrip do regarding extending the
sculpt flag from short to int.

 Index: source/blender/editors/sculpt_paint/sculpt.c
===
--- source/blender/editors/sculpt_paint/sculpt.c(revision 29142)
+++ source/blender/editors/sculpt_paint/sculpt.c(working copy)
@@ -599,9 +599,11 @@

/* Clear selection */
for(eed = me->edit_mesh->edges.first; eed; eed = 
eed->next)
EM_select_edge(eed, 0);

load_editMesh(ss->scene, ob);
+
+   free_editMesh(me->edit_mesh);
DAG_id_flush_update(ob->data, OB_RECALC_DATA); //?
}

Index: source/blender/makesdna/DNA_brush_types.h
===
--- source/blender/makesdna/DNA_brush_types.h   (revision 29142)
+++ source/blender/makesdna/DNA_brush_types.h   (working copy)
@@ -54,8 +54,9 @@
struct CurveMapping *curve; /* falloff curve */
struct MTex mtex;

-   short flag, blend;  /* general purpose flag, blend 
mode */
-   int size;   /* brush diameter */
+   short blend, pad;   /* blend mode */
+   int size;   /* brush diameter */
+   int flag, pad3; /* general purpose flag */
float detail;   /* dynamic subdivission detail 
*/
float smoothness;   /* dynamic subdivission 
smoothness*/
float jitter;   /* jitter the position of the 
brush */


___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Realtime unlimited clay

[Raul Fernandez Hernandez]

Hi all :)

 Thanks to the help of Nicolas Bishop I was able to implement Unlimited
clay in realtime :) Still I have to improve it to make it usable at high
polycounts but is definatelly a step in the rigth direction and the main
missing feature.
 Lapinou will soon update my blog with a third video showing that
functionality combined with Subsurf modifier that provides an interesting
workflow :P

   Cheers  Farsthary

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Unlimited clay status

[Raul Fernandez Hernandez]

Hi all

 A quick status report with good and bad news:

The good first :P
  I'm ready to commit when I get connected again the new patch that add
the possibility to get realtime feedback as the user subdivide the mesh,
I have set it as an option, becasue as I have feared for high polycounts
is still better to have it updated at stroke end.
  I think this kind of flexibility is good, now the user have tree levels

  -Normal sculpting (current workflow)
  -dynamic subdivission (realtime unlimited clay) (Low res)
  -static subdivission  (non realtime unlimited clay) (Hi res)

 The low res and high res threshold is machine dependant and not written
in stone ;)

And ow the bad one:
  Since the current sculpting system wasn't designed for dynamic topology
the PBVH tree which is based has no fast update function to handle
changes in topology without need to rebuild the entire tree, so the
current solution use the rebuild PBVH tree option that is painfully slow
for realtime update at relative low polycounts.

 But a derived good news is that such a function could be implemented, and
now that the problem is spotted, is the next goal to achieve.

 the new BLI_pbvh_update_mesh() function should insert the new subdivided
faces/verts in the tree as sugested by Nicholas Bishop ... a question
though: What is the best expected time for updates in a PBVH tree?

 I will preciate the help of the creators of the pbvh structure, a quick
explanation on how it works could save me lot of time trying to understnd
it from the plain source code :)

 Cheers  Raul

  Cheers  Raul



___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] unlimited clay - Arch questions

[Raul Fernandez Hernandez]

Hi all

This weekend I have made several performance tests and the bottleneck are
in this functions:

make_editMesh()
load_editMesh()
free_editMesh()
BLI_pbvh_build_mesh()

those are the more time consuming parts
 I will try to move outside the make_editMesh() and free_editMesh() if I
find a way to update the editMesh selection based on the mesh selected
verts, that is, like in the Edit mode, when the object enters sculpt mode
it could create the EditMesh structure, that will be updated in each step
(and not created/deleted) I just need to translate the base mesh selected
verts to the EditMesh verts.  this step could save lot of time.

 The remaining bottleneck will be load_editMesh() , for update the base
mesh from the editMesh, this step should be performed on each stroke, I
don't know other variant to update the base mesh than this. Is there any?
 and the BLI_pbvh_build_mesh() that hopefully will be tractable thanks to
Nicholas advices.

And more important: is there a way to modify/update/add/remove the base
mesh without call or construct an EditMesh? that way we could skip the
load_editMesh() call and get an instant update and a big speed gain, if
those conditions could be met I think we could achieve production ready
speeds in realtime unlimited clay.

   thanks in advanceRaul

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] unlimited clay - Arch questions

[Raul Fernandez Hernandez]

Hi Nicholas :)

> Hi,
>
> I think here neither the Mesh data structure nor EditMesh data
> structure is exactly what you want. Exactly the structure that you do
> want is a little harder to say of course :) Depends on how the mesh is
> being subdivided by unlimited clay.
>

 I was suspecting something like that ... you suggest as a modifier?

 I'm trying to reuse as much blender code as possible, that's why I choose
  EditMesh that has already aviable subdivission functions and more that
will be matter of plug them in the code in order to work, I will give a
last try to EditMesh to see how much performance gain I can pull of it ,
before trying other attemps.


> Anyways, it occurs to me you might want to consider writing your own
> DerivedMesh variant. Internal to your DerivedMesh, you can set up
> whatever data structure you find most helpful to accelerate your
> subdivision algorithm. Whenever the DerivedMesh is free'd, you can
> write out the changes to the real Mesh. You can also extend the PBVH
> with support for this new DerivedMesh type.
>
> The above is actually exactly how we do multires, which internally
> uses a quite different representation than a regular Mesh. In this way
> you can bypass editmesh entirely, while also avoiding hacking on your
> own changes to Mesh, which from my own experience is a Bad Idea. :)
>
> -Nicholas

 In case I have to write a new structure, how it is updated/draw in the
viewport? converting to Mesh? I hope no

Thanks a lot
Raul


___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] meetings for new developers

[Raul Fernandez Hernandez]

Hi all :)

  I really like the idea about meettings for new devs, though I feel some
envy because anything that smell to live, chat, internet is science
fiction to me :) and that brings me the question about a strong offline
support:

   What about a good offline reference, tutorials, even a book (ok, a
downloadable pdf) something like a Blender Beginers Developer´s Guide?

  Is there a plan for it in the future?
  Investing resources in documentation is by no means a waste, and often
something understimated in the open source world. Hey, a beautifull help
documentation (for users and developers) is the best marketting resource
of a software.  The main drawback of a highly dynamic program like
Blender is that the software evolve much faster than its documentation
or the features/code/UI change a lot making learning materials rapidly
obsolete but I guess it represent a defy full of oportunities and not a
source of problems.
 If someone want to make a very special contribution to Blender and is not
a developer I think this could be a good project, he even could
specilized on Blender official documentation from now on.

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Verlet integration patch (Farsthary)

[Raul Fernandez Hernandez]

Hi all :)

  Currently the particle system support 3 integrators types (in english
integrators are what actually advance particles in space and time)
and for many users that´s the kind of options that fall under the
I-always-will-use-the-default-value category,
and while for many set ups different integrators provide very similar
results, in others they could make the difference.

 The simplest integrator, Euler, is very fast but not very accurate,
internally Blender performs only one cycle of some calculations.

 The second integrator, Midpoint , is sligthly slower because it performs
2 cycles but is more accurate than Euler and is the default integrator.


 And the third , RK4 (Runge-Kutta) , as you may guess is the slowest and
more accurate of them, and performs 4 cycles of calculations in Blender


 The good news here is that I have implemented another integrator type
that is as fast as the Euler integrator (the fastest) since it requires
only one cycle of calculations and is more accurate than the Midpoint
even, the error is of fourth order: The Verlet integrator
http://en.wikipedia.org/wiki/Verlet_integration#Basic_Verlet
 have several advantages over the others and is very stable , fast, and
gives realistic results.

  this is the manual patch (is very small so will not cause any troubles
patching Blender): http://www.pasteall.org/9292/diff

 Check my site: http://farsthary.wordpress.com for more details

 I have implemented it in Blender seamlessly and I suggest it as the
default integrator, the previous integrators suffer from an increase of
energy in time, note how the amplitude of each bounce is biger than the
others in the previos integrators while in the Verlet is uniform as
should behave in a conservative enviroment (no friction,damping,etc).

 Also for many particles interacting each others the Verlet integrator
clearly shows its speed even compared with Euler. Is very easy to
implement in Blender and is a small step toward improvement.

 Could some core dev review it for commit?

   Cheers

Farsthary


___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Verlet integration patch (Farsthary)

[Raul Fernandez Hernandez]

Hi Jahka :)


> The overall idea looks nice, but the patch isn't complete. For example the
> oldpos and diff vectors aren't declared anywhere and oldpos isn't even
> defined in the patch. Besides isn't oldpos just pa->prev_state.loc?

 Ops! sorry, is that I have deleted manually some parts for better
readability but seems I screw things :)

 I didn´t knew the full state of particles, that´s why I created those
variables, but  pa->prev_state.co works fine :)

>  I'd
> also like to see vector macros used in the calculation like with the other
> integration methods (you should always try to stick to the surrounding
> code's style when poking around somebody else's code).

 Also I let the code without macros for readability also, but is corrected
now


> And while it's true that the error per timestep is fourth order (meaning
> third order total accumulated error) for location, the error per timestep
> for velocity (which you btw use to calculate the location) is second order
> (first order total accumulated error!), so I'm not convinced it's better
> than midpoint for all cases and without proper testing I can't yet comment
> on making verlet the default integration method, but I'll be happy to
> apply the patch once the couple of code issues I mentioned above are
> fixed. The question about making it default can be addressed later.
>
> jahka

  I guess you should try it, the simples set up with particles is a
colider ground with no friction/damping and particles with no
drag/damping etc, a conservative enviroment, the midpont integrator (and
the Euler and RK4) gives increasing bounces with time, not preserving
particle energy, the Verlet integrator implemented here do conserve
energy, and that is just the simples set up.

  Also try to test it with lost of particles interacting each other and
you will notice and speed boost

I have edited the patch and applied your suggested changes, Thanks a
lot :)

   http://www.pasteall.org/9364/diff

 Of course, the default sugestion was just that, a suggestion and could be
discussed later once performed several tests

 Cheers Farsthary

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] GPU computing

[Raul Fernandez Hernandez]

Hi Ishan

> Hi all,
>
> Let me start by thanking you all for the development of such a great
> software. Blender has been a life saver for me many a time. Having said
> that, I think Blender has a lot of scope for improvement, mainly on the
> performance side. A lot of commercial software in 3D modeling, rendering,
> video editing etc are starting to take advantage of GPU's computing
> ability.
> I think it is a great feature to add to Blender, and I would like to
> contribute to it.

 Thanks for your words and thanks also for your attitude :)

> However I am new to Blender source code. So I am looking for some
> guidance.
> Please give me suggestion on what API to use (CUDA/OpenCL), where do you
> think GPU computing most (rendering, video processing, etc.) and any other
> suggestions you may have. Thank you.
>
> Regards,
> Ishan

 I would recomend OpenCL, since it aims to be hardware independent, not
even just GPU but almost every piece of metal out there that could
perform calculations :) , while CUDA is currently more mature than OpenCL
is tied to NVIDIA brand :(
  And while is not an easy task what you propose I think the most needed
are are: Rendering,Modeling,Compositing

 Regards   Farsthary

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] GPU computing

[Raul Fernandez Hernandez]

Hi again Ishan

  I recommend you start with a very narrow project, even if you have lot
of skills in GPU programming, from all of the proposed areas choose
first the smaller/simpler one and go ahead, then if you succeed go for
bigger shots.

 You will get here all sort of recomendations because virtually every part
of a 3D app cry for paralellization, from rendering (the most
representative), animation, nodes/compositor transcoding, to a
neverending list.

 So gather strength in very tiny projects, even if they don't have a big
user impact, your rate of success will skyrocketed.

 Cheers

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Fixed bug of Verlet integrator (Farsthary)

[Raul Fernandez Hernandez]

Hi all :)

  Thanks to mcmacsurfer feedback I could spot the bug in the verlet
integrator and the solution was quite simple also, I was using the
pa->prev_state.co but aparently that state is modifyed/used in several
parts of the particle pippeline so changes in it could lead to strange
particle behaviours, instead return to my original proposal of using a
temporal variable that store the initial particle position at the
beginning of the function apply_particle_forces().
  Now everything works as should do.
   Thanks for the feedback
   Farsthary


Here´s the solution: http://www.pasteall.org/9538/diff

in function apply_particle_forces()

-- float force[3],impulse[3],dx[4][3],dv[4][3],diff[3];
++ float force[3],impulse[3],dx[4][3],dv[4][3],diff[3],tempos[3];

  ...

/* maintain angular velocity */
VECCOPY(pa->state.ave,pa->prev_state.ave);
++  VECCOPY(tempos,pa->state.co);

  ...

case PART_INT_VERLET:

VECADDFAC(pa->state.vel,pa->state.vel,force,dtime);
VecMulf(pa->state.vel,dtime);
VecAddf(pa->state.co,pa->state.co,pa->state.vel);


--VecSubf(diff,pa->state.co,pa->prev_state.co);
++VecSubf(diff,pa->state.co,tempos);
 VecMulf(diff,1.f/dtime);
VECCOPY(pa->state.vel,diff);
break;



___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Shading System Proposals

[Raul Fernandez Hernandez]

Hi :)

 +1 for me, my early experiments in unbiasing Render Internal with
pathtracing, and also Final gathering clearly shows the limitations of
the current shading system and prevent advaced rendering techniques and
scalability without a bunch of hack.
  With the new proposal everything will be relatively trivial to implement.

  The PBRT book and the Luxrender project are excelent references also
along with mantra.
  I have an especial question: I haven't see in the proposals the Sampler
structure, wich should be the heart of the new pippeline, it provides
the foundation of every aspect of it, from BxDFs (even for evaluating
multilayered/compound BxDFs ), Integrators, ligths, texturing, camera,
etc.

 Having the sampler independent from those components will allow the use
of efficient/smart sampling strategies in the whole Render internal.

 Also as the render gain in complex features and phisically based ones,
render times could increase and the cost of tweaks do the same for that
reason I think the system should support flexible Deep Render Buffer
(output and store not just RGBA values but any data structures/values) 
that way, for example, storing for each pixel the whole ray tree with
surface normal/color values will allow at postprocessing interactivelly
change the material/texture properties without rerender the scene.

 I would like to contribute to this development, so count on
me, though with the heavy pieces of this chess in movement I
don't think a pawn could do much :)

   All the best   Farsthary


___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] New force type patch: Spring (Farsthary)

[Raul Fernandez Hernandez]

Hi all :)

Searching to add spring forces for the fluid particles I end up with a
nice patch that adds also spring force as a new general force type that
could be used like any other blender force: for objects, particles, etc.
Needless to say the importance and wide use cases for spring forces in 3D,
previously this functionality was aviable in Blender only in
softbodies,cloth and constraints but with this patch could be extended to
particle systems for many SFX's and also to objects, te posibilities are
endless :)
 Is interesting to note how the particle system integrate features from
softbodies and fluids :)

 I will send thi spatch also to Jahka for review and commit

 Is very easy to implement and does not break any previous code, it only
will need a new UI slider for spring rest length but I'm not good at UI
coding, though it should be easy to add :)

   http://www.pasteall.org/9806/diff

  Hope you like
it,  cheers  
Farsthary :)

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] New force type patch: Spring (Farsthary)

[Raul Fernandez Hernandez]

Hi :)

> This sounds really great. Could you give and example of how it might
> be used for objects and what that might look like? I had the same
> thoughts about it as a force.
> Thanks!
>

 In my site I have uploaded some examples with fluids that adds elastic
behavior for them.
  http://farsthary.wordpress.com

 with sigle objects set to spring force you get that object extending
springs to every afected particle, and with particles set to affect
themselves with spring forces you get the typical N-body elastic
behavior.

 This fill the gap between particles and softbody, allowing a wide range
of interesting effects.

> On Mon, Dec 14, 2009 at 7:55 PM, Raul Fernandez Hernandez
>  wrote:
>> Hi all :)
>>
>> Searching to add spring forces for the fluid particles I end up with a
>> nice patch that adds also spring force as a new general force type that
>> could be used like any other blender force: for objects, particles, etc.
>> Needless to say the importance and wide use cases for spring forces in
>> 3D,
>> previously this functionality was aviable in Blender only in
>> softbodies,cloth and constraints but with this patch could be extended
>> to
>> particle systems for many SFX's and also to objects, te posibilities are
>> endless :)
>>  Is interesting to note how the particle system integrate features from
>> softbodies and fluids :)
>>
>>  I will send thi spatch also to Jahka for review and commit
>>
>>  Is very easy to implement and does not break any previous code, it
>> only
>> will need a new UI slider for spring rest length but I'm not good at UI
>> coding, though it should be easy to add :)
>>
>>   http://www.pasteall.org/9806/diff
>>


___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] New force type patch: Spring (Farsthary)

[Raul Fernandez Hernandez]

Hi :)


> Hi Raul ,
> hum .. still missing the point
> to me it looks like a force field  ( potential )  .. having a minimum
> at  R ( which you define as rest length )

  Yes, that's the potential energy of the hook's force, there's nothing
troublesome there :)


> So..
> 1. what is the point in having a potential  arranging  a mesh close to a
> S3 (sphere in 3D )

 That was just a quick/useless set up to show the effect, that is not a
real use case, a more real use case is the first video in my site, the
simple.wmv  where each particle extend springs to the rest, when you have
tons of points pulling/pushing themselves around their relatives rest
lengths interesting things happen and shapes arise, that bunch of points
(particles, etc) became elastic :)
  Also, in the first useless example you could set the center not just the
force object center but the objects vertices or every surface point and
then you will get more complex behaviors, not only OSCILATING the mesh
around an S3.

> 2. the lack of other forces .. like friction to surrounding media ..
> even internal friction ..  makes it look quite. say .incomplete
> but still
> may be i am missing the very spot, enlighten me
> BM

 This force perfectly interacts with the rest of the forces, and although
adding velocity damping is not difficult at all I think is redundant
since those effects could be achieved with the particle damping factor in
the Newtonian panel. Think of it as a system and not as an isolated
force, the rest of the system have drag forces,damp factors etc, so for
complex behaviors like dampen springs you just set them also and there's
no need to increase force complexity adding those alreday calculated
therms to the force source code.
 (Againg, if there's some use cases that justify it in the force source
code it will be a matter of minutes to add it)

   Cheers   Farsthary


___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] New force type patch: Spring (Farsthary)

[Raul Fernandez Hernandez]

Hi BM


> These features are in soft / cloth but handled in a context specific way.
> I'd like to see them i a larger, more general framework.
> For cloth ( hair is even worse )  i am not sure if it works since it
> must use topological properties of the mesh for untangling and such,
> but  borders from viscous particle fluids to soft 'solids' are not
> really there.  ( Only depends on the spring structure inside )
> So it should be possible for soft bodies.

 Yes, the spring force for particle systems add softbody-like behavior but
not hair-like/cloth-like because as you said it requires topological
information that by its very definiton a particle system don't have and
also is not needed.
 The spring force is juts another force type (like vortex, magnetic, wind,
etc), a force type that have its use cases, is not an attemp of
unification of the physics system, it just add elastic behavor to the
particle system in a consistent and easy way.
  In theory a particle system could became everything and include all
simulation effects (cloth,hair,softbody,fluids,smoke) and while
having a general physisc framework is a desirable feature I don't think
is feasible rigth now but that should not be an excuse to let the users
waitin for those features.
   What we (Stephen,Jahka,me) are doing is adding those behaviors to the
particle system: now spring forces that adds elastic/plastic
softbody-like behavior and soon SPH particles that add fluid like
behavior.
  Specialization vs generalization will always be an eternal debate and I
think the best option is a mix of both.

  This patch add a simple spring force type, we are working also in a more
softbody like model with dynamic arrays of springs that perhaps fulfill
more the rigid/sorftbody target. :)


> On the long run i can imagine the entire soft body module moving to there.
> Though the mayor part of the soft body code deals with building up and
> managing states of
> complex spring structures with respect to ( vertex group ) painted
> distributions of mass, spring constants and damping.
> Accumulation of forces and solving differential equations is the far
> smaller part :)
> Beside it deals ( in pretty clumsy way ) with edge vs face collisions
> which particles due to the vertex only nature
> don't need, but would need for nice hair. As i said before hair is even
> worse. Good hair needs collision and untangling of strands
> -> definitely makes use of topological properties.
> Still, that would be a very nice unification of the 'spread all over
> physics' right now.
> Don't know how that fits to the mesh modifiers then?

 Again, I don't think it will happen, while particle systems could feature
sotbody behavior I think there always be cases where an especialized
softbody implementation that could use the topological information of
meshes is the best choice and in the case of clothes and hair is even
less possible.
   But then again, I don't think is a necesity :)

> I think damping along the spring direction is needed:
> Think of a vertex orbiting around the centre an only radial components
> decay.
> (And yes i know it is a 3 liner, if the velocity of the vertex is
> available)
> For more complex meshes that would keep the motion of the entire object
> but eating
> 'inner' vibrations. Like a lava eruption from a planet with no
> atmosphere and too small
> to keep the lava blob in range via gravitation.

 While that could be achieved curretly simply increasing the particle damp
value it will not harm then implementing velocity damping inside the
spring force.


> Finally i have to say: I am very impressed/pleased to see which
> direction the 'physics thing' is taking and
> like to be constructive, productive, helping .. when ever i can.
> So don't take this as  /ME rants 'will never work .. grumble'
> but things i'd like to be thought of before making decisions.
> BM

It's OK :) , I preciate every feedback and I really thank you for
taking your time and discuss this topics with me, your doubts could be
the doubts of many and we all end up winning here ;)

I still need the approval of Jahka to take some design decitions but
if it gets in I could elaborate with more time an extensive
documentation and tutorials about this feature, since a video tells
more than words :)

Cheers  Raul (Farsthary)

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Development plan proposal for after the 2.6 series

[Raul Fernandez Hernandez]

> Hi all,
>
> I'd like to propose that after the 2.6 series completes that we start
> scheduling patch review and perhaps have a development focus.
>
> My thoughts were to have a  1 or 2 month rotating cycle where we focus
> on one area of Blender and try and bring that area to be the industry
> leader in terms of speed of workflow and capabilities.  During that
> time period I'd recommend we have a commitment to review all patches
> that are relevant for that area - of course coders could review other
> patches as well that are relevant to them, but with a schedule outside
> coders can have a clear idea of what code base they need to have their
> patch current against, and have a clear timeline about when they can
> expect their code to be reviewed.  Also with a schedule - artists can
> have a clear timeframe to submit ideas and proposals and mockups.
>
> I'd recommend that we order the development similar to a production
> pipeline (Ie similar to how Durians development timeline is ordered).
>

 +1 on me, development focus is the only way to leverage the weak areas of
Blender because as much as skilled/talented may be a dev he can't compete
with a well organized team. If the UI/event system overhaul haven't being
a dev focus it probably never happen so the big task should be
accomplished with teams.

  But is also good to maintain the flexiblity because many good things has
came to Blender outside the official projects and the priority schedule
could became a discriminating factor , the 3d world is very dynamic and
priorities changes from one year to the other.





___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Unifying Spring with Harmonic force (Farsthary)

[Raul Fernandez Hernandez]

Hi all :)

   Thanks to Jahka feedback where he told me that he suspected that the
current harmonic force acts in a similar way that my spring
implementations I have performed some research and he is rigth, just
that the harmonic force don't consider a rest length parametter.

   So I have merged both implementation into one, the Harmonic force now
use the Spring force code with rest length and reuse the previous
Harmonic velocity damping. Now everything is ok, if the user set the
rest length of the new Harmonic to 0 he will get the old harmonic
behavior and if set its value to any other he will get the new Spring
force nehavior.

  the new patch is at

http://www.pasteall.org/9882/diff

   now it requires even less changes :)

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Development plan proposal for after the 2.6 series

[Raul Fernandez Hernandez]

Hi

> I think this plan could work, but only if the BF invested funds in
>paying relevant developers for the duration of each cycle.  I think
>this is effectively what the open movie projects accomplish, without
>the requirement that the new features must be tested in production of
>
>Joe

   Why not small Open Dev projects (one-two month cycle) similar to the
Open Movie project but instead of focusing on a final movie investing
funds in all the necesary machinery for that (which I consider is very
effective for its goal) the output of such Open Dev projects could be a
small but well elaborated features demo/documentation.?

  Just a pointless thougth





___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] killer feature: multifluid interactions for fluid particles done! (Farsthary)

[Raul Fernandez Hernandez]

Hi all :)

  Fluid - Fluid interactions or Multifluids interactions are responsible
for a wide range of effects and events in nature and heavily used in the
CG insdustry.
  While the Elbeem fluid simulator integrated in Blender is pretty
powerfull is designed for single fluid simulations (I mean, you can't
mix oil with water in it for example) but in SPH particles that is no
longer an issue :) and if that where achieved it will automatically
became a huge feature for the fluid particles :)

 So as my christmas present for the whole Blender community I have
implemented full multifluid interactions for the fluid particles in
Blender!
you can mix any number and any fluid types!! (hardware provided ;) )

  I have sended Lapinou the videos for posting soon in my site, so check
it regularly: http://farsthary.wordpress.com

  I show there three videos, one where two fluids, red and blue, get fully
mixed, one with those get partially mixed and finally one with two
fluids that don't mix each other and form the well known fluid-fluid
interface or boudary.

  I'm very exited about it :)

  So far, fluid particles are almost ready and feature near complete in
the simulation side (after official commit we still add dynamic spring
arrays for shape gloas and rigid body like behavior), so now the main
issue remains the surface generation that will be tackled soon.

  After that Stephen and I will send a patch to Jahka for review.

   Have a nice christmas
    Raul Fernandez
(Farsthary)


___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Sticky particles (or sticky surfaces) patch (Farsthary)

[Raul Fernandez Hernandez]

Hi all :)

   The good news continue arriving :)  I have added yesterday a stickness
factor to the particle collider objects, this will allow more
interesting effects as I will post soon in my site, like wet surfaces,
etc.

   Coding it as a property of the collider object and not of the particles
will allow to set up scenes with different colliders that respond
diferently to the same particle system.

  the patch is at: http://www.pasteall.org/10045/diff

   Is very easy to commit as it will require few lines of code but the
benefits are enormous, it works with all particle physics types and
especially well with the upcomming Fluid particles.

Hope you like :)



  Raul Fernandez



___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Multiple Ligth Scattering buggs correction (Farsthary)

[Raul Fernandez Hernandez]

Hi all :)

 Congratullations and Happy New Year!

  I spend the whole day yesterday fixing old buggs in the volumetric code
regarding Multiple Ligth Scattering since it was not behaving as should
do.

I also have made a few performance improvements to the code, like for
example, in many places where appears multiple calls to the indexing
functions V_I() in the same scope , calculating it once and stored in a
variable and then call it when needed, it saves some multiplications :)

 I have sended the patch to Matt Ebb for review and commit, it should not
be very difficult to apply, in case someone want to take a look at it I
attach it at the end of this mail.

 Here's a summary of the squashed buggs ;) :

   - they where a non correspondence between the LC and the MLS buffers,
they follow a different alligment that lead to incorrect fill process
if use a single indexing function for both. (I have corrected the
indexing in the MLS buffers)

   - The actual diffussion process where something like ...
  x[]=x0[]+a(x[]+x[]+...)/(1+6*a)
where should be
  x[]=x0[]+a(x0[]+x0[]+...)/(1+6*a)
   each simulation step is only dependant on previous step or buffer.

   - The MLS buffer where not initialized and filled with the single
scattering pass before the actual simulation start, in the
shade_one_lamp() only the single scattering trigger the LC calculation,
where should be triggered also in the Multiple scattering and the
shaded+Multiple scattering cases. The MLS should start from the single
scattering filled ligth cache.

   - the Multiple scattering was called after the filtering function calls
where should be called BEFORE, because the filtering function may
introduce artifacts that later will get amplified in the MLS simulation
process.

And finally, this is not a bug but a correction: the diffussion parametter
is in range 0.0 to FLOAT_MAX , where it only have sense in the range
0.0-1.0, higher values than 1.0 have no effect,does not increase the
diffussion:

  in file rna_material.c

prop= RNA_def_property(srna, "ms_diffusion", PROP_FLOAT, PROP_NONE);
RNA_def_property_float_sdna(prop, NULL, "ms_diff");
--  RNA_def_property_range(prop, 0.0f, FLT_MAX);
++  RNA_def_property_range(prop, 0.0f, 1.0f);
RNA_def_property_ui_text(prop, "Diffusion", "Diffusion factor, the
strength of the blurring

effect");
RNA_def_property_update(prop, 0, "rna_Material_update");

--- here's the complete diff patch --

diff -r /home/raul/Escritorio/Previous/volume_precache.c
/home/raul/Escritorio/Modified/volume_precache.c
24c24
<  * Contributor(s): Matt Ebb.
---
>  * Contributor(s): Matt Ebb, Raúl Fernández Hernández (Farsthary).
137,139c137,139
<
<   if (cache[ V_I(x_, y_, 
z_, res) ] > 0.0f) {
<   tot += cache[ 
V_I(x_, y_, z_, res) ];
---
>   int i= V_I(x_, y_, z_, 
> res) ;
>   if (cache[i] > 0.0f) {
>   tot += cache[i];
167,172c167,173
<   if (vp->data_r[ V_I(x, y, z, vp->res) ] < -0.f)
<   vp->data_r[ V_I(x, y, z, vp->res) ] = 
get_avg_surrounds(vp->data_r,
vp->res, x, y, z);
<   if (vp->data_g[ V_I(x, y, z, vp->res) ] < -0.f)
<   vp->data_g[ V_I(x, y, z, vp->res) ] = 
get_avg_surrounds(vp->data_g,
vp->res, x, y, z);
<   if (vp->data_b[ V_I(x, y, z, vp->res) ] < -0.f)
<   vp->data_b[ V_I(x, y, z, vp->res) ] = 
get_avg_surrounds(vp->data_b,
vp->res, x, y, z);
---
>   int i= V_I(x, y, z, vp->res);
>   if (vp->data_r[i] < -0.f)
>   vp->data_r[i] = 
> get_avg_surrounds(vp->data_r, vp->res, x, y, z);
>   if (vp->data_g[i] < -0.f)
>   vp->data_g[i] = 
> get_avg_surrounds(vp->data_g, vp->res, x, y, z);
>   if (vp->data_b[i] < -0.f)
>   vp->data_b[i] = 
> get_avg_surrounds(vp->data_b, vp->res, x, y, z);
175c176
<   }
---
>   }
181c182
<   int x, y, z;
---
>   int x, y, z;
197,202c198,204
<   if (vp->data_r[ V_I(x, y, z, vp->res) ] < -0.f)
<   new_r[ V_I(x, y, z, vp->res) ] = 
get_avg_surrounds(vp->data_r,
vp->res, x, y, z);
<   if (vp->data_g[ V_I(x, y, z, vp->res) ] < -0.f)
<   new_g[ V_I(x, y, z, vp->res) ] = 
get_avg_surrounds(vp->data_g,
vp->res, x, y, z);
<   if (vp->data_b[ V_I(x, y, z, vp->res) ] < -0.f)

Re: [Bf-committers] Shading System Proposals

[Raul Fernandez Hernandez]

Hi :)

> Also, in my experience, letting the BSDF compute the wo must be done with
> care. It is not a good idea to let the BSDF have its own independent
> sample
> generator. If two different BSDF sample generators are corelated for
> several
> consecutive paths, this can (and generally will) produce moiré or lisajou
> or
> caustics artifacts.

 That's what I was refering when I said that especial care should be put
in the design of a good sampler, it is the heart of every Monte Carlo
algorithm and could not be substitute with combination of RNG functions.


> A strategy that works well is to use a
> multiple-dimensional sampler per path and you need as many (times 2)
> dimensions as there are bounces in your path. Each bounce requires 2 more
> dimensions. For example you need dimension 1 and 2 to sample the light
> surface and 3, 4 to sample the direction from the light surface. Then you
> would need dimensions 5,6 to sample the bounce direction from the BSDF on
> the hit point, etc. Sobol sampler can do that by using different prime
> numbers for every dimension. This strategy can be hard coded in the BSDF
> but
> it would be more flexible in allowing someone to develop different path
> sampling strategies if another sample() function could take u and v
> parameters and use those with a warp function to sample the distribution.
>
>> * intensity estimate: given in vector (or not)?, integral over
>> outgoing directions

  A global sampler must be set, a multidimensional one like PBRT does,
that way every aspect of the shading system could take advantage of
better sampling strategies, the sampler itself could be a node that
provides samples to every other node that need it. Firstly keep it
simple, one or two simple sampling algorithm but later, once the system
is functional more strategies could be easily and independently added.


Regards   Raul

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] fire simulation

[Raul Fernandez Hernandez]

Hi Lukas

+1   I found very interesting your proposal and while the current
simulator and volumetric rendering could achieve very cool fire effects I
think a dedicated simulator will be much more artist friendly and usefull,
so go ahead! is a very nice project.

  Cheers Farsthary


___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Particle diffussion or mixing fluid properties

[Raul Fernandez Hernandez]

Hi all :)

Previously, when I show the mixing fluids feature of fluid particles I
only sowed the physical behavior of the mixing fluids and as was pointed

by Daniel Genrich , it still missed mixing mixable fluids or diffusion.

  Well, the good news is that properties diffussion is pretty
straigthfoward to add, not just color could be diffussed among mixable
fluids but just everything (temperature, etc) and as a proof of concept
I have implemented color diffussion :)

Currently is only at viewport level (OpenGL level) and I need to thinker
more on it to make it usable for end users , but is a nice insigth of what
will come in the future :)

 for some screenshots and a video visit my blog:

   http://farsthary.wordpress.com


   cheers

Farsthary

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers