PDA

View Full Version : My New Best Idea!!!® this year(?): "PARSE NAME" node /reducing nodal labor



jeric_synergy
03-22-2013, 12:43 PM
XSwampyX generously provided me with a network that allowed me to light up Surfaces depending on the Y-channel location of a control null. Gracias. In shamelessly copying his technique, I came upon an issue for lazy people like myself:

Swampy's technique involves specifying a number in the network for each surface. This number is compared to the null's location, some math is committed, and if the number matches the null's location the surface is made non-transparent. If not, the surface is 100% transparent.

So, two things need to be specified: the control null and the number. This is dull work-- I had 20 surfaces to apply. ( "BORing!!")

The user can (IIRC) save the labor of specifying the null by SAVING the Surface and reLOADing it. But TMK each number must be changed manually, one-by-one.

Since each surface needs a unique name, that's boring labor also. But it's boring labor that's already done.

It occurred to me that if the Nodal System could

Parse the Surface Name
users could embed information in the Surface Name and use ONE loaded surface to do the job, without having to change the network at all.

And since you can multi-select Surfaces and LOAD a Surface en-masse to all of the simultaneously, for this kind of network that addresses many similar Surfaces, this PARSE NAME node results in easier maintenance and faster application.

So, that's my idea: a "PARSE NAME" node that would evaluate the current Surface into nodal scalar values for use by the node network.

An immediate elaboration would be some protocol to embed multiple values in the Surface name, using delimiters or whatever strikes the programmer's fancy.

And after all this typing, please tell me this doesn't exist already...

EDIT: this would be especially handy for programmatically generated surfaces, where a plugin or script may have generated dozens or hundreds of Surfaces.

Lightwolf
03-22-2013, 05:33 PM
shaderMeister comes with a nodes that allows you to extract values from item comments.
Alas - not surface comments, as these don't seem to be readable through the SDK.

Cheers,
Mike

jeric_synergy
03-22-2013, 05:42 PM
Achh! So close! ;)

Since you say "seem", I wonder if a dev could give a definitive answer on that issue. It'd be super handy.

Lightwolf
03-22-2013, 05:51 PM
Achh! So close! ;)

Since you say "seem", I wonder if a dev could give a definitive answer on that issue. It'd be super handy.
Unless they've used (or implemented) it themselves... they're not likely to know either. Or there's internal hooks which aren't helpful from the outside either.

As a side note, the nodes in shaderMeister also take hierarchies into account. If the named value they look for isn't present in the current item, they go up the hierarchy until they find a match - and if not, use a default.

Cheers,
Mike

jeric_synergy
03-22-2013, 06:05 PM
As a side note, the nodes in shaderMeister also take hierarchies into account. If the named value they look for isn't present in the current item, they go up the hierarchy until they find a match - and if not, use a default.
I'm afraid the implications of this escape me. :(

Lightwolf
03-22-2013, 06:55 PM
I'm afraid the implications of this escape me. :(
Well, you need a default value in case nothing can be parsed.

And since it's item based, you can, say, apply a comment to the parent (which may even be a Null) of a set of items but have it affect all children (unless one of them has an individual comment that can be parsed).

Cheers,
Mike

Sensei
03-22-2013, 11:06 PM
Do you think that node is receiving info what surface it's in??
No.
It's receiving just polygon id..
You have to waste a lot of cpu power to convert it to what you want.. And parsing string is another way to waste cpu power..
Now multiply it by number of pixels on screen and by number of aa passes..

jeric_synergy
03-22-2013, 11:59 PM
Do you think that node is receiving info what surface it's in??
No.
It's receiving just polygon id..
Well, if Micheal can have a node that evaluates Item comments, I don't think extracting a Surface Name is so radical a concept. Can polygon IDs be pointers to a Surface?

I'm not qualified to estimate cpu requirements , nor do I care. I'm with Steve Worley on this: if a feature is cpu intensive, it's up the the USER to decide to use it or not, not the vendor.

This might result in slow renders, but it could radically speed up some setups, and make them easier to maintain. Renders happen while I sleep, I value setup speedups a lot.

Sensei
03-23-2013, 12:51 AM
Well, if Micheal can have a node that evaluates Item comments,

Reading comment is probably just one line of code:
const char *comment = iteminfo->getTag( nodalaccess->objID, tag_id );


Can polygon IDs be pointers to a Surface?

LWPolID is pointing (probably) to polygon structure, some memory,
that structure probably has field for surface id/index.
It's all black-box.
And plugin can't read it. At least plugin not pretending to be hack that works with just one exact LW version and crashing with other.
In every LW version structure is/can be updated and changed.


if a feature is cpu intensive, it's up the the USER to decide to use it or not, not the vendor.

If something is really cpu intensive, user will try it once, find out it's slow, and then stop using as useless feature and programmer will simply waste time programming thing that's useless.

Lightwolf
03-23-2013, 07:21 AM
You have to waste a lot of cpu power to convert it to what you want.. And parsing string is another way to waste cpu power..
Now multiply it by number of pixels on screen and by number of aa passes..
That would be the simple way of implementing it. Luckily it can be optimised easily. The comment nodes are fast... very fast.

Cheers,
Mike

Sensei
03-23-2013, 07:29 AM
Comment from item info is completely different story than polygon surface name..
LWItemID is almost immediate index to array- in initialization code just scan all items in the scene, take comment from them, compare with string from GUI or extract value from string, then set field in table.. And in evaluate just read field from table..
In evaluate it's faster code than Math > Scalar > Add ;)

jeric_synergy
03-23-2013, 02:07 PM
Do node writers get a scratch-pad area? If so, a one-time evaluation would be possible.