Thanks a lot, dear Animatrix.

edward
APEX is sort of a "mid level" graph in between SOPs and VOPs. From the TD perspective, it's like VOPs except that you can manipulate geometry as data that flows through the graph along side with small data types like vectors, floats, and matrices. Unlike VOPs though, the graph not run in a per-element fashion, making it more like SOPs in that respect.

The primary driver for APEX was KineFX rigging performance. Up until now, KineFX rigging was a mix of SOPs and VOPs. There were a few limitations with that:

• Adding new data types to VEX (which is what VOPs translate into) was daunting and KineFX really needs to manipulate geometry along side with matrices/vectors/floats.
  
• Single rigs were inefficient in VEX because of its per-element nature. Running VEX in detail mode wasted a lot of memory because it was designed to run the graph over many elements of the same type. Extra memory was allocated but never used when running in detail mode.
  
• Performance was lost in the switching between SOPs and VOPs. A way to assemble rigs in a modular fashion which can then be executed directly in the viewport without the need for heavy nodes was needed.
  

This opened up the opportunity for designing a graph engine that had some architectural benefits that are not really user facing: things like easy data and node type extensibility, decoupled compilation and execution, and enforced static dependencies by construction. By design, it's fairly generic so it can be used to solve other graph-like evaluation problems in the future.

I don't think it replaces SOPs and VOPs. Compiled SOPs is more efficient at working on single pieces of geometry, VOPs is more efficient when you need operate over many elements of the same type. To produce your rigs, SOPs is still the glue for everything else outside of the rig.

This is amazing dear Edward.
I have a question about what you wrote.
If geometry is modified somewhere inside a compiled block, Doesn't this modification cause Houdini to cook everything from the beginning of the compiled block? Since we know in compiled blocks Houdini steals the geometry instead of copying it.
How does Houdini handle this scenario?
Thanks a lot.

Hello.
I hope you are doing well.
I just add a Shrinkwrap node and set its type to 2D to create a 2d convex shape for the input model.
Take a look at the attachment.
Hope it helps.

Soothsayer
I'm also confused but I have a few thoughts:

- I don't trust the gradient calculation, I never have. Something's not right about it but I don't know what. You can easily get weird results.

- That aside, I don't trust the vector calculations (advect) and the viewport so I did a little test where calculate the dot product. They hover neatly around 0, as they should. The vectors however don't always look right.

- Maybe something with face vs center sampling might interfere but sometimes I can't calculate a gradient at all out of it.

So, I don't know but I have a feeling Houdini isn't telling us the truth.

I attached a file.

Thanks a lot.
You know the real reason behind the zero dot product is that the lengths for the pressure gradient vectors are too small.
If you normalize both divergence-free and pressure-gradient fields you will see the dot product is not going to be zero anymore!
As you visualized both divergence-free and pressure-gradient fields they are not orthogonal in any way!
I also tested it with VDB project non-divergent node with no luck!

Hello everyone.
I encounter a weird problem.
As you know Gas Project Non Divergent nodes use the Helmholtz-Hodge decomposition to decompose a velocity field into a pressure scalar and a divergent free vector fields.
The gradient of pressure and divergent free vector field should be orthogonal to each other but when I look at the volume trail they are not orthogonal in any way!
No matter how hard I crank up the resolution the result is always the same.
The red lines are divergence-free portions and the green ones are curl-free portions.
I also attached my project in case anyone wants to look at it.
Does anyone have any solution to this problem?
Thank you so much.

vik_lc
This might be interesting Nerd Rant: Math & Papers [www.youtube.com]. Moritz and Manuel implement algorithms from papers in their tutorials from time to time. But I'm not too deep in the subject to give you advice here, even if what you say is plausible. All I can say is that understanding such papers and being able to implement them are two essential things, I think often one of them fails - finding practical causes is often difficult.

Good luck and success.

Thanks a lot I really appreciate it.

Digipiction
I've tried and failed at doing this numerous times in the past. Usually the papers end up referencing other papers that contain information you need to know, skipping steps, discussing things in an overly mathematical fashion etc.

Sometimes the concepts are really really easy, but instead of explaining them in a brief sentence they're presented as a crazy equation.

How a normal person might describe it:
We have a 3d cylinder. We loop over all the points, find each point's neighbors and average out those positions. We assign the newly averaged position to the point, thus smoothing the entire mesh.

The way a paper might describe it:
Let V = {v_i} be the set of vertices in the 3D cylindrical mesh, where i = 1, 2, ..., n, and n is the total number of vertices. For each vertex v_i, let N(v_i) be the set of neighboring vertices. Our mesh smoothing algorithm can be described as follows:

For each vertex v_i in V, compute the centroid C_i of the neighboring vertices:
C_i = (1/|N(v_i)|) * Σ_{j ∈ N(v_i)} v_j
where |N(v_i)| is the cardinality of the set N(v_i), representing the number of neighboring vertices for v_i.

Update the position of each vertex v_i with the computed centroid:
v_i_new = C_i

Repeat steps 1 and 2 for a predefined number of iterations or until a convergence criterion is met.

The proposed algorithm redistributes the vertex positions by calculating the average of their neighboring vertices, effectively smoothing the mesh and improving its overall quality. This iterative process can be tuned according to specific requirements, such as the desired level of mesh homogeneity or an acceptable error threshold.

Yes, this is exactly what I'm talking about.
I'm not sure why they are insisting to write this way!

alexwheezy
It is for this reason that it is not even easy to understand just by reading some article only a few people among many thousands of artists are always doing this. They write new solvers, implement new algorithms and it seems to me that this requires much more than just desire.

Thanks a lot I really appreciate it.

tshead2
N-G:

Rightly-or-wrongly, computer science papers are often judged on whether they "can be implemented by the average graduate student in the field", which may-or-may-not describe your circumstances. The mathematical notation is intended to capture high-level ideas without tying them to the language / OS / programming paradigm of the month. If you stick with it long enough, it starts to make more sense.

Cheers,
Tim

Another problem is that every paper tries to show the world that their approaches and methods are the best among the others. You can't tell anything about it until you finally test yourself after putting in an endless amount of time to implement them correctly.

animatrix_
That's why there is not a single skill as being able to understand any white paper. It all depends on the subject matter, algorithm and the paper at hand.

I find it best when the paper has some code or at the very least pseudocode associated with it.

Thank you so much dear @animatrix_.
You know, the code is available rarely. Many paper writers decide not to publish their code on the internet.
I remember implementing the lattice Boltzmann method in Houdini and there were a couple of good examples on the internet that made it unnecessary to read such nonsense papers but as soon as you wanted to add more things to it such as interaction with moving obstacles you need to read them again!
Therefore for implementing simple things you need to waste a lot of time reading and comprehending these papers and hope in the end you have something in your hands.

Now, my questions boil down to:

1- Why journals don't stop accepting papers with this format? How do they even convince themselves that the proposed methods work the way shown in the papers?

2- Whose responsibility is to read and understand these papers not just overall but also to implement them?
technical directors? research and developers? software developers? technical artists? etc...

3- Are there any resources to force paper writers to upload their full work with complete validation, verification, and explanation?

4- How do such papers extend with such conciseness whereas no code and further information are shared to put them in a real challenge?
I found many similar papers trying to explain similar topics without proposing anything new!

Looking forward to your answers guys.
Thank you so much.

Hello guys.
I hope you are doing well these days.

I decide to read and implement scientific papers (specifically Siggraph ones) that I'm interested in various topics such as medial axis, straight skeletonization, two-way coupling between solid and fluid, various fluid implementations like state-of-the-art smoothed particle hydrodynamics, and many more...

Many of Houdini's features are based on these papers such as grain, vellum, FLIP, APIC, narrow band, etc.

The problem that I'm facing now is how to understand these papers for implementation and not just to know what's going on generally.
I showed some of these papers to experienced university professors who had a degree in mathematics or engineering but in the end, they refused to follow up for further investigation or information.

Now my question is why these papers are so concise that even university professors reject to follow them up due to the energy and time it takes to comprehend these topics.

For whom are these papers written?

How can the scientific community accept such conciseness (besides validating that they even work with the quality shown) in these papers despite the fact that professionals need to put so much effort to comprehend them?

Are there any resources so that the complete form of scientific papers is available?

I would greatly be appreciated it if anyone can shine a light on this topic.

Thank you so much.

Anyone?
Is it so hard?

luoqiulin
an OSL shading node such as Code Snippet is nice.

In material context press the tab and type OSL, you will see a node like a snippet for the OSL.
Isn't it what you want?

سلام خانم خادم امیدوارم حالتون خوب باشه.

Why didn't you use the impulse attribute provided by the glue constraint itself?

I cleaned your dynamic network a bit and set the strength attribute in SOP to -1.
Setting this attribute to -1 in conjunction with using a Primitive Wrangle to look up the break threshold separately will result in faster simulation than a very high strength number since the bullet tries to look up the break threshold on every frame.
I attached the project file and correct it based on the impulse also notice how much it's faster now.

Please keep me posted if you still have trouble.

Hope it helps.

Hello guys!

I encountered a weird problem with Ray Hit VOP which is used in the material context.
I attached a very simple project with an explanation can anyone explain how this node works?
Intersection with other objects returns the wrong result or not intersecting at all which sounds really strange to me!

Thanks in advance.

tamte
To optimize your calls consider using Cache If SOP which can detect the geometry changes and trigger cook only when relevant

Dear Tomas,
Can Cache If SOP detect if an animated parameter doesn't change on each frame even though it may contain expressions like floor($F * 0.1)for instance?
Based on what I experienced so far seems it can't understand it and recooking happens every frame instead of every 10 frames!
Is there any trick involved?

My approach to this solution is to bring a python sop and then call the proper HDA-defined function.
You can call it via:

To be more specific this happens because Houdini doesn't have enough information to calculate the final buoyant force to defeat gravity.
If you increase sim resolution (reducing Particle Separation) you will get the proper result.
Another cheaper way is to only increase the collision resolution (reducing Collision Separation) portion of the sim itself.
You can find feedback force information under the impulse subsection of the feedback sub-data of each RBD object.
Hope it helps.

Hello.
Just give the Isovalue option in VDB Convert a small positive number like 0.001.

animatrix_

N-G
Thanks a lot, man!
I'm just curious to know why SideFX doesn't add the eigenvector function to VEX!

VEX have svddecomp (singular value decomposition). I posted an example of it here:
https://www.sidefx.com/forum/topic/84345/#post-364636 [www.sidefx.com]

This is one of the topics I plan to cover in Pragmatic VEX: Volume 2.

Thanks a lot, dear @animatrix.
I am in doubt if SVD decomposition can yield eigenvectors of a matrix, instead, it gives eigenvectors for matrix times transpose of the matrix!

Thanks a lot, man!
I'm just curious to know why SideFX doesn't add the eigenvector function to VEX!

Is this too hard really?

Hello!
This happens mainly because either your graphic card's driver is outdated or your graphic card model is outdated at all!
If you want to be able to go further you should set the OpenCL device to use CPU instead of GPU.
To this end you should go to Edit -> Preferences -> Miscellaneous under OpenCL device and set the Type to CPU instead of GPU.

Did you use stash node to store a geometry inside your node network?
You can also freeze geometry as well.