Results 1 to 12 of 12

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

  1. #1
    Axes grinder- Dongle #99
    Join Date
    Jul 2003
    Location
    Seattle
    Posts
    14,726

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

    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.
    Last edited by jeric_synergy; 03-22-2013 at 12:50 PM.
    They only call it 'class warfare' when we fight back.
    Praise to Buddha! #resist
    Chard's Credo-"Documentation is PART of the Interface"
    Film the cops. Always FILM THE COPS. Use this app.

  2. #2
    obfuscated SDK hacker Lightwolf's Avatar
    Join Date
    Feb 2003
    Location
    Stuttgart, Germany
    Posts
    13,541
    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

  3. #3
    Axes grinder- Dongle #99
    Join Date
    Jul 2003
    Location
    Seattle
    Posts
    14,726
    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.
    They only call it 'class warfare' when we fight back.
    Praise to Buddha! #resist
    Chard's Credo-"Documentation is PART of the Interface"
    Film the cops. Always FILM THE COPS. Use this app.

  4. #4
    obfuscated SDK hacker Lightwolf's Avatar
    Join Date
    Feb 2003
    Location
    Stuttgart, Germany
    Posts
    13,541
    Quote Originally Posted by jeric_synergy View Post
    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

  5. #5
    Axes grinder- Dongle #99
    Join Date
    Jul 2003
    Location
    Seattle
    Posts
    14,726
    Quote Originally Posted by Lightwolf View Post
    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.
    They only call it 'class warfare' when we fight back.
    Praise to Buddha! #resist
    Chard's Credo-"Documentation is PART of the Interface"
    Film the cops. Always FILM THE COPS. Use this app.

  6. #6
    obfuscated SDK hacker Lightwolf's Avatar
    Join Date
    Feb 2003
    Location
    Stuttgart, Germany
    Posts
    13,541
    Quote Originally Posted by jeric_synergy View Post
    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

  7. #7
    TrueArt Support
    Join Date
    Feb 2003
    Location
    Poland
    Posts
    7,803
    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..
    LightWave Plugins
    Global Materials for LightWave 2019
    Custom plugin writing. Request a quote.

  8. #8
    Axes grinder- Dongle #99
    Join Date
    Jul 2003
    Location
    Seattle
    Posts
    14,726

    the user decides if a tool is too slow

    Quote Originally Posted by Sensei View Post
    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.
    They only call it 'class warfare' when we fight back.
    Praise to Buddha! #resist
    Chard's Credo-"Documentation is PART of the Interface"
    Film the cops. Always FILM THE COPS. Use this app.

  9. #9
    TrueArt Support
    Join Date
    Feb 2003
    Location
    Poland
    Posts
    7,803
    Quote Originally Posted by jeric_synergy View Post
    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.
    Last edited by Sensei; 03-23-2013 at 12:53 AM.
    LightWave Plugins
    Global Materials for LightWave 2019
    Custom plugin writing. Request a quote.

  10. #10
    obfuscated SDK hacker Lightwolf's Avatar
    Join Date
    Feb 2003
    Location
    Stuttgart, Germany
    Posts
    13,541
    Quote Originally Posted by Sensei View Post
    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

  11. #11
    TrueArt Support
    Join Date
    Feb 2003
    Location
    Poland
    Posts
    7,803
    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
    Last edited by Sensei; 03-23-2013 at 07:35 AM.
    LightWave Plugins
    Global Materials for LightWave 2019
    Custom plugin writing. Request a quote.

  12. #12
    Axes grinder- Dongle #99
    Join Date
    Jul 2003
    Location
    Seattle
    Posts
    14,726
    Do node writers get a scratch-pad area? If so, a one-time evaluation would be possible.
    They only call it 'class warfare' when we fight back.
    Praise to Buddha! #resist
    Chard's Credo-"Documentation is PART of the Interface"
    Film the cops. Always FILM THE COPS. Use this app.

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •