-
@deeeds I would prefer Spawn on Object to spawn the new object on the layer the object is currently in. If you want the new object to spawn on a different layer, make its first action move to the layer you want. Or use Spawn on Area with the object’s coordinates as the position.
-
@aidan-oxley I bet money with myself you'd say something like this.
It's a bug of design. Layers should respect the origin of their content. Not least because the user has chosen to use layers for that reason... the layering.
Also because this is how layers work, by design and convention, in all other software.
Also because the tools you describe for moving things between layers can be used inversely, when optimisation isn't the purpose of using layers, when convenience is.
But mainly because of what I mention, that it creates serious conflicts with the manner in which the different coordinate systems can and should be used between the different TYPES of layers and the different ways to differentiate between layers.
Whilst I recognise you've grown accustomed to how hyperPad operates, and you (personally) benefit from that familiarity, these other reasons far outweigh your personal preferences and aren't just my personal preferences, they're objective considerations of the experiences and potentials of the app and others.
-
Also because this is how layers work, by design and convention, in all other software.
Can you give an example? In Paint.net and similar programs, when I copy something on one layer, then switch to another layer and hit paste, it pastes on the layer im on. With spawning, it spawns on the layer the spawner is on.
I imagine people would be confused by it either way.
-
@jack8680 said in Spawn Doesn't Respect Layer of Origin:
I don't know what this is.
TL;DR version:
The ON part of Spawn On is the important destination object's geometric position, not its layer position, which is the instance parent's space and place in a hierarchy of all objects, and should be respected by instances, by default.
If you apply the positional information of one item to instances of another item, the instanced items respect their layering in all other creative software I'm familiar with. This includes, but is not limited to: Maya, 3ds Max, C4D, AE, Illustrator, Flash and even Photoshop actions using folders/groups.
The information about placement is taken from the source of location/area (Spawn On's equivalent) and applied to the instances, with instances being created relative to layering placement within the technologies and hierarchical structures of their original creation and/or placement.
This is also true of the creation of visual effects like particles, flares, filters and instances within game engines that use similar mechanisms and/or structural sorting facilities.
The concept of "Spawn on" is almost always used to define position in geometric space (the ON part), not ruin or reorganise the structural spacing of layers and their children, which are retained and respected by the instances created "on" the "target" object's geometric positions. Otherwise there's little point in having layers as an editor function, as they're now only theoretical and code based.
-
This is by design. If you’re using spawn on object, then you’re spawning on top of that object, meaning it will be in the same layer that the object your spawning on top of. . If you want to respect the original objects layer then don’t use spawn on object, instead use spawn.
-
@murtaza This is poor lexicon choice.
Rename it:
Spawn IN Object - this wording you should use for this functionality. This terminology use conveys and contains hierarchy semantics.
Spawn ON Object should be reserved for being ON the geometric space of an object, absent of location IN hierarchy.
What I'm suggesting is also congruent and consistent with:
Spawn ON Area, however, and here's the problem with your response, this also disrespects the original layer of the spawned object.
-
@deeeds sorry, but “spawn in” sounds retarded.
“on” implies same position. And since layers don’t interact with each other, it can’t be ON it if it’s in a different layer.
And it goes with spawn on area because area would be position, but it doesn’t require it to be in the same layer. -
@itap-development Probably because you've never used a good particle system.
-
@deeeds said in Spawn Doesn't Respect Layer of Origin:
@murtaza This is poor lexicon choice.
Rename it:
Spawn IN Object - this wording you should use for this functionality. This terminology use conveys and contains hierarchy semantics.
Spawn ON Object should be reserved for being ON the geometric space of an object, absent of location IN hierarchy.
What I'm suggesting is also congruent and consistent with:
Spawn ON Area, however, and here's the problem with your response, this also disrespects the original layer of the spawned object.
I think it's fine. As do the users over the past 6 years, and the countless classes we've used hyperPad in. Of all the things we've had to explain and go over, spawn on object has never been one of them.
Changing it now is far too late. We're in too deep ;). -
@deeeds What I said has nothing to do with benefitting me, it just makes more sense that if you spawn something on top of an object, the spawned object is on the same layer as the object it spawned on. It could have a toggle, but what does it matter? It’s so easy to switch layers it’s not worth the time to change how this works.
-
you said...
If you want to respect the original objects layer then don’t use spawn on object, instead use spawn.
i said...
this also disrespects the original layer of the spawned object.
Common sense AND convention of spawning's uses in all other environments trump your anecdotal experiences with a dozen users and naive newbs, regardless of the timeframe. Particularly because they're going to move on from your app to the rest of the world's creative products, most of which use the following conventions.
Spawn AT (doesn't exist in hyperPad, is a specific point. Requires user fudging in hyperPad)
Spawn [with]IN (geometric space inside a shape, and what you call Spawn On)
Spawn [up]ON (geometric space along the edges of a shape. Doesn't exist in hyperPad)None of these alter hierarchical structure, they always respect the editor layering (by user) where it's available. Layering, sorting and other hierarchical choices of a user are always presumed deliberate and therefore respected. Layering is a completely different type of sorting, in a different place, for different reasons, none of which pertain to geometric space, except Z-sorting in 2D, in which case the layer sorting becomes imperative to the user, and should be respected by the engine for this reason, alone.
That should be reason enough to consider respecting layering choices of an end user. But I see it's not. So let me make other cases:
-
Your app is a gateway drug to the worlds of digital creativity. If you want to be fondly remembered, referenced, revered and referred to, your best bet is to match your tooling, paradigms and processes to where your best (and most influential) users will eventually find themselves. Then those 6 years of users experiencing your product might actually mean something to others, and help create exponential user growth.
-
Most obviously and logically important, when layering matters most (performance optimisation), the processes of manually moving newly spawned objects between layers will further hurt already tight performance constraints the user is deliberately using layers to attempt optimising around. So your current approach confounds the very best possible use of layers.
I apologise if my making of more than one point is confusing, or bewildering. Also, sorry if my appeals to logic, rationality and reason distort your constrained perspective.
-
