Mouse Brain

[Macha]

Hm. I checked around a little and it appears that threading is not a good option here. Python threads run single-processor and are useful only when one part of the program is waiting for another. As of 2.6 there is a module supporting multicores but that's no good for Houdini-folk yet.

At least that's how I understand it.

One way of making it faster is to use a different underlying network. Reducing point-neighbors is quite useful and I am experimenting with voronoi patterned surfaces. They give a nice irregular pattern and have less connections than a delaunay mesh (what I use now).

I'll have to think about if I and how I could make it more adaptive...

[Macha]

In today's update I smoothed moving paths. In the example below the original path is in grey, the smoothed path in red.

If start, goal or waypoints nulls are moving then a new path is calculated for every frame. This results in jumping. To alleviate this I:

- added a CHOP to blend between the paths of every frame

- equalized point numbers along these paths

- applied another CHOP to the mouse's path travel in order to smooth any jumps resulting from sudden path stretching (it can chance spacing between the NURB points)

(The tip of the path is trailing but that's just an aesthetic decision and I could have kept it stuck to the moving goal.)

Edited January 26, 2010 by Macha

[edward]

I've just been only casually paying attention. Does VEX/VOPs help with any of this? Esp. if you want multi-threading.

[Macha]

I've just been only casually paying attention. Does VEX/VOPs help with any of this? Esp. if you want multi-threading.

Well, it was an exercise to learn Python so I tried to avoid vex. But now at this stage I'm thinking it could be useful. Do you know if it is possible to call VEX from inside Python? I know I can access Hscript via hou.hscriptExpression. If that was possible with vex, there could be useful functions for this.

[graham]

There's currently no way to call VEX code from within Python.

[Macha]

I have improved speed quite a lot with this recently by adding vex code to calculate neighbors and an improved path finding algorithm.

The bottleneck is the neighbour calculation. It becomes very slow over 3000 points (15 seconds perhaps). I also noticed that vex doesn't multithread, even though it is often said to do so.

Luckily the neighbours do only have to be calculated once per geometry.

Below are stats for the pathfinding for a scene with 3 waypoints.

number of points 100

number of edges 180

Time: 0.0149998664856 seconds

number of points 400

number of edges 760

Time: 0.108999967575 seconds

number of points 900

number of edges 1740

Time: 0.266000032425 seconds

number of points 1600

number of edges 3120

Time: 0.655999898911 seconds

number of points 2500

number of edges 4900

Time: 1.39100003242 seconds

number of points 3600

number of edges 7080

Time: 2.42200016975 seconds

Edited March 29, 2010 by Macha

[Macha]

In the image below I have used a different algorithm.

It is not the shortest path that is calculated here but just a path (but still a short one). This results in a much faster calculation. So fast in fact that it spits out several hundred paths at once in less than a second.

Here they spawn from points across the sphere and converge to a common target.

The bottleneck here is neither the neighbour calculation, nor the path finding but the mesh generation of the wires, by an order of magnitude!

All paths 973
Time: 0.296999931335 seconds

Video:

[dyei nightmare]

In the image below I have used a different algorithm.

macha you should be my houdini teacher, how much do you want to teachme?

[Macha]

I can make some rather cool veins stuff with those paths!

[eetu]

I can make some rather cool veins stuff with those paths!

So you can!

An update from Macha makes for a better day.

Edited March 30, 2010 by eetu

[wigal123]

cool stuff! time to share some code

[mightcouldb1]

This looks great. Care to share the theory behind it?

Edited March 30, 2010 by mightcouldb1

[Macha]

Maybe if I get it clean and neat one day I can share the code but for the moment it is too much like a home-build machine that needs a drop of oil in the right place every now and then, or a piece of string wrapped around a pipe here and there.

As for the most recent one, the idea behind it is to calculate all the paths at once (very fast though because real euclidian distances are disregarded, only path-steps are counted), write them out to a file dictionary, and then sample from that dictionary, loop through it, and build paths. As a pre-step I also mess up the point positions via sop network, while keeping the shape, otherwise the paths are too regular and look like a pattern.

[Macha]

New video here:

[Macha]

Mouse has gone to space to chase cheese planets. So, she can now hop randomly through a cloudpoint, avoiding her own path, but still getting to the cheese relatively quickly.

I suppose this could be called a targeted self-avoiding Brownian path.

She can interpolate the paths between the points of the cloud, so she makes straighter paths.

Video:

Edited April 6, 2010 by Macha

[Macha]

The same as before but prettier.

Not all the points in the cloud are visited (small spheres). Just those that lead from start to goal.

Video:

Edited April 6, 2010 by Macha

[Nerox]

Hi Marc!

Wow, I find this totally awesome :-D. As an exercise I'm building a similair system using A*. I wonder how did you go about storing the neighbour information? You can use vops to get the neighbours, but where do you store it? All I can think of is creating an x number of attributes on each point which you can use to store neighbor point numbers. I wonder if this is the best way to do this, since I fear that it will create a lot of overhead in terms of memory, I mean how many neighbors are you going to support?

It's to bad that Python appears to get slow when going over connected neigbors, since if you could compute it on the fly you would never have to touch points you aren't going to visit anyway. Especially with highly detailed maps it would make a huge difference I guess.

What's your opinion on this?

Edited July 7, 2011 by Nerox