LW 2020.0.3 Instance Info Index ID error/bug?

M

Meshman

New member
Is anyone else having issues with the 2020.0.3 Instance Info node and the ID Index output?

This one's probably worthy of a bug report.

I've tried trashing configs and a fresh install but the problem looks to be within LW2020. Couldn't find mention of it on the forums, so I'm posting to see if anyone has similar issues or possible solutions.

Images show that the setup works as expected in 2019.1.5, but in 2020.0.3 all instances inherit the last color key, in this case key #9 ouputs red.
 

Attachments

  • instance_info_index_id_2019.1.5.png
    instance_info_index_id_2019.1.5.png
    312.2 KB · Views: 240
  • instance_info_index_id_2020.0.3.png
    instance_info_index_id_2020.0.3.png
    250.3 KB · Views: 248
Well, I don't have 2020.0.3 installed but I tried it with 2020.0.2 on Windows and can confirm that it's not working as described in the reference manual (for me anyway).

Anyone else?
 
1) fill bug report (anyway)
2) for simpler things you can use Fixed Random. 0...1 range, multiply by quantity of instances. Figure out mapping between F.R. and ID manually.
 
Yes seems something changed, id indexes are different,
did you try to change "constant" by "repeat" for the post behavior of the Gradient node?

Denis.
 
Denis is right.. there must be a very large starting index..
Use Math > Scalar > Mod:
Grab.png


Grab 2.png
 
Last edited:
You can get the same ID index than 2019,
by substrating a "odd nine-digits composite number"
268435457
or in binary
1 0000 0000 0000 0000 0000 0000 0001

Some kind of mystic metanumber in LW2020?

Denis.
 
Thanks for the confirmation and workarounds everyone, a bug report has been submitted for this.

Additionally, I performed the same basic test on a MacBook Pro and can confirm the errant indexing behavior is present with the LW2020 Mac version.
 
dpont said:
You can get the same ID index than 2019,
by substrating a "odd nine-digits composite number"
268435457
or in binary
1 0000 0000 0000 0000 0000 0000 0001

Some kind of mystic metanumber in LW2020?
Click to expand...
Try cloning an object with instances... neither subtract nor modulo fixes permanently...
 
I used the TextGen node for displaying the ID index,
replaced this not so weird number by the Item ID,
this is the Surface of the instance reference,
so this is the Item ID of the reference,
I cloned the first Null instancer twice,
then added a Null without instance generator,
cloned the Null instancer again.

2020_IDInstancer.jpg

The Instance ID index seems to be shifted by the Instancer ID index.
If we could substact the Instancer ID index, instances ID index would be identical in clones instancer



Denis.
 
Last edited:
dpont said:
You can get the same ID index than 2019,
by substrating a "odd nine-digits composite number"
268435457
or in binary
1 0000 0000 0000 0000 0000 0000 0001

Some kind of mystic metanumber in LW2020?

Denis.
Click to expand...
Wouldn't that be a signed vs unsigned integer typecast error in the code? If they miffed something and switched variable type from unsigned to signed, hence the 1st bit of the 32bit integer being 1 designating a positive integer? (all this is off the top of my head and I might be completely off my rocker. )


Scott
 
This may seem a silly question but aren't the last 4 bits reserved in layout for telling lightwave what kind of item the ID number that follows is?

I'm kind of fuzzy on the Item ID in general, but I seem to remember that they're unsigned 32 bit integers, with the 4 highest bits reserved for what kind of ID the lower 28 bits are...

Too bad you can't do a bitwise AND in nodes. Taking the ID AND 0x0FFFFFFF would get you a valid integer ID (0x00000000 - 0x0FFFFFFF).
 
Kryslin said:
Too bad you can't do a bitwise AND in nodes. Taking the ID AND 0x0FFFFFFF would get you a valid integer ID (0x00000000 - 0x0FFFFFFF).
Click to expand...
Math modulo with 2^n will have similar functionality.
e.g.
x mod 16 is equivalent of x & 0xF
x mod 256 is equivalent of x & 0xFF
x mod 65536 is equivalent of x & 0xFFFF

Modulo is:
x - ( ( x / y ) * y )
(if there is no built-in operator)
(as long as working with integers)
 
Just to add some extra info, in case I fall foul of this bug again. The number that Denis subtracted '268435457' is the default SEED value inside the instancer.
If you make this seed value '0', the Index ID works as it used to.

Definitely a bug though. Weird. But thanks for all your help here people!
 
lardbros said:
Just to add some extra info, in case I fall foul of this bug again. The number that Denis subtracted '268435457' is the default SEED value inside the instancer.
If you make this seed value '0', the Index ID works as it used to.

Definitely a bug though. Weird. But thanks for all your help here people!
Click to expand...
268435457
is
hexadecimal
0x1000 0000
 
I understand Sensei, but just trying to help other artists. Knowing that hex for 268435457 is 0x1000 0000 doesn't help me fix a visual problem. I'm not a coder, nor can I read binary or hex code.

Just removing the seed value from the Instance Generator fixes the original problem without any other maths or messing about. :)
 
Last edited:
You must log in or register to reply here.
Back
Top