PDA

View Full Version : LWM: in EDIT KEYS, "Set Tag" command-- function?



jeric_synergy
03-15-2015, 07:54 PM
in the EDIT KEYS window, in the COMMANDS classification, there is an entry for SET TAG.


What does this do? :stumped:


Thanks.

ernpchan
03-15-2015, 08:06 PM
I think it's Genoma related, but not 100% sure. How to use it, I couldn't say.

Sensei
03-15-2015, 08:08 PM
In LWSDK tag is simply part or surface.

polTag( polid, tag, value );
if tag is part, value is name of part,
if tag is surface, value is name of surface.

I guess so it's alternative way to assign them from command.

jeric_synergy
03-15-2015, 08:12 PM
Hmmmmm.... 'fossil' feature?

Sensei
03-15-2015, 08:31 PM
Not necessarily.
Scripts can call such internal commands.
Fracture has such commands that you never execute. Tool is executing by itself.

lino.grandi
03-16-2015, 04:09 AM
Hmmmmm.... 'fossil' feature?

Not at all.

Being able to set a polygon tag through scripting has been a long standing user request. Now it is possible.

jeric_synergy
03-16-2015, 11:18 AM
But a TAG is both a Surface and a PART, depending on command syntax? (Just trying to get this straight.)

Kinda related: hey Lino, has there ever been a move to establish a better 'PART' entity that avoids the limitations of PART? Currently, TMK a polygon can only be a member of one PART. An obvious extension of this would be, for instance, a 'GROUP', which would be for Polys what SELECTION SETS are for Points. Essentially, PARTS that can have some overlap.

Heck, you could still use the TAG command, just add GROUP to the possible arguments.

EDIT: I'm NOT suggesting PARTS be eliminated, just that GROUPS be added. They serve different functions.

Sensei
03-16-2015, 12:14 PM
Tag in computer science is data associated to specific object.

You don't have list of polygons (that's what you described). List can be expanded when member is added, or shrink when member is removed.

But in LW 1st polygon which has part tag "part1", 2nd polygon which has part tag "part1".
Because strings are same they're visible to user as one.
To know which polygons are part1 programmer has to scan all polygons in mesh, get tag, and compare strings strcmp(name1,name2)==0 - they're the same.

Similar is with human born nationality.
One person is British, other person is Polish,
you can't have both at the same time.

Adding groups where poly can be member of multiple groups like you want would require completely different SDK functions, with new LWO changes etc.

Sensei
03-16-2015, 12:17 PM
It could be slightly cheated. Suppose so we will introduce separator like ","

And have Add To Part, Remove From Part commands
to what is already f.e. "part1", Add To Part will append "part2",
and it will become "part1,part2"
Would require rewriting all functions displaying and changing parts.. But without changing SDK and LWO.

jeric_synergy
03-16-2015, 12:46 PM
Adding groups where poly can be member of multiple groups like you want would require completely different SDK functions, with new LWO changes etc.
Understood Sensei: that's why I discussed it in the context of a new feature/entity.

But, as you point out, this current methodology seems very, VERY inefficient if it requires a function to scan all existing polys to determine if they are members of a PART. Would it not be far superior to maintain a separate list of poly id's in an array that is essentially the PART (or by extension, a 'GROUP')? A PART (or future GROUP) can be very few polys-- scanning hundreds of thousands of polys just to determine if they are members seems like a very bad idea.

So, my feature request would be the implementation of GROUPS via a separate array, keyed to poly ids. Any GROUP array could contain any poly id, so this would overcome the current limitation of PARTS.

Sensei
03-16-2015, 12:54 PM
Do you know what is alternative?
Having to add/remove polygon from/to dynamic list while CREATING geometry. Which means a LOT slow down while it's needed to work fast.
You don't that often scan all parts polygons. It's rarely needed functionality. But slow down would be happening ALWAYS going your way..

Sensei
03-16-2015, 01:10 PM
Adding element to dynamic list is only fast for double-linked lists (it's used by LW, and is a problem ;) )

Typical list (not double-linked) has quantity and elements, one by one in computer memory.
To add element, you need to allocate memory count+1, copy all elements, and add new entry to the end.
To remove element, you need to search for entry, find index, and copy'n'paste all other elements -1 index.. (so the slowest will be removing 1st element, as it requires copying entire table)

There are many tricks to make it faster, like allocating in groups, f.e. chunk size=16 entries (reallocation every 16 added entries).
But still, it's slowing down.

List has 1 million entries? You will have to copy block 4*1 mln = 4 MB (32 bit) or 8*1 mln = 8 MB of memory on 64 bit computer.
Check how fast computer can copy memory..
According to
http://en.wikipedia.org/wiki/DDR3_SDRAM
DDR3 @ 100 MHz has 6400 MB/s max (PC3-6400)
6400/8=800
Program made this way could add/remove just 800 polygons per second to such dynamic list with 1 mln polygons count!
Not 800 thousands, simply eight hundred.

jeric_synergy
03-16-2015, 02:48 PM
Do you know what is alternative?
Having to add/remove polygon from/to dynamic list while CREATING geometry. Which means a LOT slow down while it's needed to work fast.
You don't that often scan all parts polygons. It's rarely needed functionality. But slow down would be happening ALWAYS going your way..
Is that because the polygon IDs are constantly changing??

Sensei
03-16-2015, 03:04 PM
Is that because the polygon IDs are constantly changing??

ID of polygon remain the same.
But new polygons are added, and old polygons are removed, during editing.

Suppose so user is deleting polygon, all groups must be examined to find in which groups they were added. Scanning all of them takes time. Removing entry from group they're attached to, takes time.

jeric_synergy
03-16-2015, 04:26 PM
There may be a language barrier here, but:

If polygon IDs are are STATIC (are they?);
You do not have to remove a polygon from a GROUP list until the object is saved. Because it doesn't matter if an entry in a group array is invalid: if it's invalid, it's just skipped. (At save time, you'd clean the list of invalid entries.)

Also, I didn't specify any kind of auto-adding to a group-- new polygons are not added to a group until the user specifically designates them as part of a GROUP (just as polys are not automatically designated as a PART currently).

In use, I would imagine that groups would be a very small subset of an object's total polygons, so only a fraction of the total number of polys in an object.

Sensei
03-16-2015, 05:05 PM
Currently ID is pointer to memory where is point/polygon.
If point/polygon is deleted, memory is freed, and all references to it must be cleaned up and removed (therefor need to remove from all lists). Otherwise it would end up in cpu exception illegal memory access (the main reason for FPrime crashes - plugin didn't know some pointer is no longer available, because it was deleted and memory freed).
You can't leave deleted entry.
It would end up with taking whole computer memory in a while.

If ID would be index, and index would be marked "deleted", then every tool would scan through millions of inactive, already deleted entries, checking them and finding "entry is deleted", before reaching active one (appended to the end of lists)..

Polygon which is not in any named part is still in unnamed part.



If polygon IDs are are STATIC (are they?);

Unofficially.

Officially tool can't store them between invoking different tools.

But I am doing so in SelectionPresetManager
https://www.youtube.com/watch?v=j2ZjSKGJxqE

In Core ID was index, thus this tool could not be made on Core.

jeric_synergy
03-16-2015, 05:44 PM
I still think there's some misunderstanding here: in my mind, GROUPS are not stored/embedded in the poly database, they are a separate list.

Sensei
03-16-2015, 05:51 PM
Separate lists must be constantly checked & modified, when user is editing mesh.. To be up to date, and not contain obsolete (deleted) references/pointers.

jeric_synergy
03-16-2015, 07:18 PM
Sure, but I think it would be worth doing because:


1) It's functionality we do not currently have.
2) AS USED, the overhead may be so minimal that it has no perceivable user impact.

IOW, the common case may be far less onerous than then worst-possible case. I think the data could be structured in such a way to minimize constant RAM thrashing.

Currently, if I want to have the functionality of GROUPS, I use POINT SELECTION SETS and immediately switch to SEL POLYS, but A) there are ambiguous cases and B) it's kinda bullsh~t hackery.