Looks like writing a script in paramter line yields different results than loading it from file.

After running select script from file, the code from docs actually works
message $SELECT_NAME
Also message $SELECT_PICK
returns a message box with a value of 1 (correctly).

But the rest of variables (SELECT_SHIFT etc.) returns an empty message box and an undefined variable error.

At least I know they are not defined.

Does anybody have a clue how to get to them?

I haven't resolved it.
No progress so far.

How to use SELECT_SHIFT, SELECT_ALT and SELECT_CTRL variables in select script of a node?

Is it actually in use or is it an odd feature?

Buzz tuts are worth every penny.
Very in depth, cuts through the basics fast.

It gets stranger.
I got to this results via complete accident.

The following script displays an empty message box:
message `$SELECT_NAME`

The next code displays an empty message box and after that a correct message box, containing a name of selected object.
message `$SELECT_NAME`
message `$SELECT_NAME`

But most surprisingly, the following script displays one, correct message box, containing the name:
#message `$SELECT_NAME`
message `$SELECT_NAME`

This is a partial success.
I'm not sure why it works like that.
Also, with SELECT_SHIFT it doesn't!

Perhaps there is a dark cloaked way of getting it to work?

I'm pretty sure, see attached file.
With SELECT_PICK unset the node is not being selected.
I just can't get SELECT_NAME and SELECT_SHIFT to work
no matter if inside quotes, tildes or without.

These guys work as supposed:
message $F
message `$F`
message “$F”


For sure I'm making some mistake, but haven't spot it so far.

I'm trying to setup some script expression using SELECT_NAME, SELECT_PATH, SELECT_SHIFT … _ALT , _CTRL variables.

Unfortunately I can't even succeed in running:
message $SELECT_NAME
straight from docs.

It just pops an empty message box.

All of these SELECT_* variables are highlighted red in the editor.
I thought they are no longer supported, but SELECT_PICK actually works.

Getting selected node is obviously not a problem, stardard variables like $OS and expressions (e.g. `opfullpath(“.”)`) works exactly like expected.

But the thing is I badly need the SELECT_SHIFT, SELECT_ALT and SELECT_CTRL.


first post from eonssss haa !

285 works all right, thanks!

I also had incorrect powerplan setup, and Houdini switched to intel when on battery

:roll:

I sense that houdini version greater than v8 (sic!) doesn't respect quadros
My oldie precision M70 is unable to run houdini.
It's just an old typewriter now.
But why (?!) brand new w520 displays poo in H viewport?

Never had problems with any cheapo geforce though.

I swapped the drivers and it worked for a while, but now again there are
strange black stripes, empty windows, no point attribs in scene viewer etc.

I don't know what's going on.
Perhaps it's the lack of black panther or laser blaster image on the box.
Or the name of computer is not evily spooky enough

ok, seriously…
Do you know a rock solid driver version for this setup?

I hope this is what you looked for.
Poindcloud functions are the way to go.

I'm not sure if this can be achieved.

Initially, without any additional attribs, curves render facing the camera.
This can be easilly checked by creating custom orient attribute, poitning towards camera.
It changes nothing.
Also if I correctly understand curve rendering they don't use up vector, just orient and curve direction.
Orient is an up vector for curve rendering.

Rendering a curve of the same pixel width would require perspective copmensation.

The problem arises because mantra builds a real 3d curve, not simulate it as post effect.
There is no way you could sweep a line along a curve and avoid twisting.
It will always shade as real ribbon, unless you destroy the normals or put a constant shader which doesn't use them.

Serwus Danilo!

I wrote this is silly because the same functionality is duplicated in align VOP if I'm not wrong.
Also I could get object xform matrix instead of building one from normal, but found this super simple way too late.

The acos(dot()) is a very standard mathematcal way of getting angle between two vectors.
It comes from basics of dot product.
Dot product of two normalized vectors is a bare cosine.
arccosine is the opposite of the cosine, it returns an angle in radians from cosine value.

Perhaps we are talking about two different things.
I computed three euler angles just to build xform, and push it through cracktransform.

For l-systems, the documentation is very good and clears most of things.

Premise is just what is generated from the start. Putting there a variable like “A” ensures you that there is no geometry before 1st generation.
Each generation step the l-sys runs through the rules.
At first it reads the premise “A”, but doesn't know what it is (unlike built in variables like F f etc.).Then is reads the rules and produce A from them.
You can put any global variables into premise and geometry is immediately built (in generation 0).

If you like to dig in the l-systems subjects, there is a great site : http://algorithmicbotany.org/papers/#abop [algorithmicbotany.org]
The biggest publication about l-systems is “Algorithmic beauty of plants”.

About scripting in houdini…There is VEX - SIMD language very similar to rsl, with C-like syntax. It's very fast, and you can write (or place VOPS) your own operators with it. All mantra shaders are vex, you can write geometry operators, image operators etc.)
Python is houdini scripting language, like MEL. It replaces Hscript. With python you can script any aspect of the software, it has functions for wrapping HScript and VEX and C++(!).

Also I strongly recommend you to read the docs, they are great and better with every update.

One thing concerning houdini speed. You can read everywhere how slow houdini is. It's not the entire truth, houdini can have slow viewports, character rigs are not that snappy, DOPS, POPS blah blah. BUT in case of many geometry operations, houdini is truly fast. Let's make a 100X100 grid, put polyExtrude SOP and inset the polygons…now do that in 3dsmax…

Have you tried cracktransform function?

EDIT: VOP way.
Hope this is close, I only think this way of building xform from N is silly

Hi LitoNico,

What Arkadiusz has done is a great piece of work.
The tools you need to create similar imagery can be built in houdini, you don't need any other software, only talent and hard work

If you'd like to do such simulation stuff you really should get into SOP Solver.
If I'm not wrong Peter Claes posted a very nice hip file with fighting particles some time ago.
Perhaps somebody has a link?

L Systems are a great building block, e.g. to achieve phylotaxis distribution just put A in premise and A(i)=F(i)+(137.5)A(i+0.1) into rule of Lsys SOP.
Also pull generations way up to a 100 or more.

You can build everything in houdini but with this power there come a noisy learning curve. Hopefully there are plenty of good tuts today.

It's the same.
Sorry if I was not clear enough but I meant you should just create rsl SHOP type and put rsl code inside.

Creating RSL SHOP types under /VEX or in VOPnet?

VEX can't create geometry, only modify and create attributes.
To create geometry you could write a python SOP, but they are usually slower than node setups.

You could create an attribute in VOPs and add lines based on that attribute.
I did it with nearpoint expression though.
See attached file, it's a very dirty brutal way though.
With larger point number, points on the same box get connected too.

HTH

Houdini is a well established consistent environment, which gives you “creative freedom” you Never Even Smell in any other 3d app … at some cost.

It wasn't too religious, was it? :wink:

I created light streaks with curves. Here's a dirty scene. Perhaps it could be of some help.

Peter

Thanks for clearing it Diula.
The longer I dig the subjects the more questions arise.
How are pointclouds different from normal gi/fg cache in MR or Vray or mantra irradiance cache.?

I know they can have more purposes but what about data acceleration structures in all of them?

I understand pointclouds are so efficient in use with scanline rendering, but houdini pointcloud shader for ao/gi uses raytracing on points, how is it different from MR/Vray caching?

It's not adaptive so we get more points where they are not needed. It's not prefiltered so we loose memory efficiency = using photon/irradiance/whatever atlas is impossible now.

Still…if we have an atlas(whole scene pointcloud or brickmap as in pixar paper) how does it differ from eg. MR fg/gi cache generated for whole scene, apart from rendering technique difference?

Are these all cache points using different acceleration structures and access way?

3delight pc's are not load into memory.

I'm puzzled and tired, don't get it too serious

Some icing yet:

Does new prman server use the ao/color bleeding technique pixar writes about in a paper with palmtrees (http://graphics.pixar.com/library/ [graphics.pixar.com])?


EDIT: ok, I'd better get lost <VeRy hApPY>