What's the difference between nested prefabs and prefab variants?

Looking at the video it seems as if prefab variants are just nested prefabs that use the overrides to create variants, however since things are clearly presented as separate I'm wondering if I'm missing something there...

 

Its if you want to create a different variation of the prefab, so it's like having a master shader (Nested Prefab) and different materials that's based on it (Prefab Variants).

 

You basically inherit the things from your base prefab and can modify it there, if you add things to the base class, those changes will appear in the variant too.

 

It's practically the same. Say you have a Prefab called 'A':

If Prefab 'A' contains another Prefab as a child GameObject, we call that a nested Prefab.

If Prefab 'A' has another Prefab as its root GameObject, then Prefab 'A' is a Variant and we called the other Prefab its base Prefab.

So it's really all about whether it's a child GameObject or the root GameObject.

In both cases you can have overrides on the other Prefab. And in both cases, if you make changes to the inner Prefab, you will see those reflected in the outer Prefab ('A') too (except if they're overridden).

 

You could be more explicit, and choose better words as terms. Unity's naming conventions are bad, there's no need to go from bad to silly levels of bad.

In the above sentence, when you say "that", you're probably referring to Prefab 'A' being termed the "nested Prefab", not the child GameObject. But it doesn't read that way, at all.

But it's silly levels of bad because "nested Prefab", from any version of English I'm familiar with, talks about the Prefab that's nested, which would be the child GameObject Prefab, not Prefab 'A'.

While you're at it, why do you stipulate it as a child "GameObject", not just as a child? Is there any other form it could take, other than being a child "GameObject"? Why not simply refer to it as a child, that happens to be a Prefab?

Further, can Prefab 'A' "contain" a Prefab as anything other than as a child? It might be that the word contain already indicates that the "child" Prefab is nested within Prefab 'A'.

Now you're conflating and abusing the language further, using root instead of Parent, within the context of a conversation started about nesting, and Variant, seemingly, to describe a child, and base to also describe the parent. Why?

Has nobody sat down with a pencil and paper and rubbed out all the words that aren't necessary to describe this functionality and capability?

I'm beginning to get the feeling you're being deliberately as ambiguous and inconsistent as possible, to try to make this more complex and seemingly clever than it really is. Or just had too much coffee.

Now you're just taking the mickey out of the reader, surely.

Yep, fully taking the piss.

 

I forgot to mention:

"base" should absolutely not be used in this situation.

It's the wrong family of metaphors, if you'll excuse the pun.

 

No, I was referring to the inner Prefab being called a nested Prefab, not 'A' being called Nested.

If 'A' has a nested Prefab inside, we don't call it anything special. It's still just a regular Prefab. (Unless it's a Variant - because Variants can have nested Prefabs inside too.)

Just to be explicit. We have seen that people tend to use child/parent terminology for all kinds of things, so better safe than sorry.

Prefab 'A' can contain another Prefab as its root, as I said. That would make Prefab 'A' a Variant, and the other Prefab would not be a child. It would be incorrect to say that the word 'contain' indicates that it's a child, since it can also be the root.

I'm not. A parent is part of a parent-child relationship, whereas a root is the topmost object of a hierarchical structure.

If you have a structure with A that has child B that has child C, then A is parent to B and B is parent to C, but only A is the root, and there is only one root in a given structure. When we talk about the root of a Prefab, we mean the topmost GameObject in the entire GameObject hierarchy of the Prefab.

I can't figure out why you think I use Variant to describe a parent and base to describe a child. Try to use Variants a bit more; or see the video explanations of them. If should become clear that Prefab Variants don't need to have any parents or children at all.

Yep, most definitely. You can see a glossary of all the words here:
https://docs.google.com/document/d/...LvrR6SZbnWn-jKk8Q/edit#heading=h.be48a5igfbb4

We don't have graphs or pictures in the glossary, but it might be an idea. But there are lots of imagery in the documentation and videos that hopefully make all the terminology more clear!

 

Avoiding other terminology, what is a Prefab Variant?

It is not, at all, clear.

 

This is about as clear as mud.

Unless we have different definitions for root objects, I see no way an object can contain another object and treat the contained object as its root.

By my sense of the word root, as in root object, it's the highest object in the hierarchy, and any children it has treat it as their root.

 

I don't think this helps. At all.

 

That analogy is clear for all programmers who know basics of OOP.

https://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)
https://en.wikipedia.org/wiki/Object_composition

 

Ah, that makes sense! Thank you for the speedy reply

 

And why do you think he's a programmer?

BTW, for me, the definitions are mostly clear (obviously it's a new system, I will have to familiarize myself with it more) and I don't think it's bad at tall.

 

exactly right.

When you discuss visual, hierarchical, nesting of deliberately designed, pseudo physical objects, primarily created in a visual editor from visual elements and attributes, as templates capable of being instanced, like symbols in design software, the primary user audience are (for the most part) not programmers.

It's a design and design iteration tool that's geared towards being converted to a "class" like thing upon being made into a "prefab".

But the language, so far, to discuss this stuff, is unbelievably unwieldy. There must be a way to communicate these things, and their full functionality, in less than two full sentences, without resorting to terminology foreign to a designer. Unfortunately I don't understand what you've tried to do with prefabs and "variants", at all, so you'll have to find someone better able to decode absolutely garbled efforts at communicating, or able to bother trying. I can't do either.

Get someone with zero knowledge of prefabs and coding, and ask them to come up with ways to describe this functionality. Explain to them the functionality WITHOUT using ANY terminology... do not bias or otherwise divert them from using their natural language and design oriented terminology to describe what you're describing.

If you can't describe this functionality without resorting to terminology, find someone who can.

The results will be very insightful.

 

Dude, relax, it uses many terms because it is not a trivial system. And the terms that it does use are the most suitable for what they describe. They made videos, wrote forum posts, they even wrote a friggin glossary... come on man, be a bit reasonable

Maybe wanting to using an incredibly complex piece of software actually requires becoming a bit familiar with the terminology of the topics involved...

 

This is pure comedy gold:



What facilities are you trying to provide via Nested Prefabs?

Break it down from an end user perspective, as though selling the time to use Unity. Do not presume Unity is enticing, enjoyable or intriguing. Sell it by explaining what’s at its core, and unique to Unity.

Start from the beginning, and get simple. It takes a lot of careful time to explain things in a simple manner, I understand. But this has been 10 years in the making, and the waiting, it seems, and sits at the guts of what Unity is about.

The above looks like it's been thrown together during a weekend, complete with caveats and caveat emptor, builtin.

 

Example.

GameObjects and their Components, in a Unity World

A Unity GameObject is the simplest of things; a unique identity and position, naked.

Adding Components to GameObjects gives them appearance and capabilities.

Game Objects can be nested to other GameObjects. Like a man and his gun.

When the man moves, the gun moves. Man aims. Man shoots. 'Kaboom'.

Game Over.

 

It happen to have garble jargon terminology when you just solve a difficult problem, it is the legacy of all the meandering before achieving a solution, they are still in the honey moon period where it all clicked using those jargon tools. I mean nested prefab has been a difficult gestation of 9 years, with many reboot.

Give them time, or gave them your own understanding.

I mean it's like AI programmer trying to explain NN using probability term, but when you look at the math from a fresh outsider perspective it's no more difficult than a bill from the supermarket, and error computing is basically a simple game of find the magic number (which is easier to get than gradient fracking descent). I mean frak logistic regression.

 

Prefab Variants are going to need this:

 

I still haven't got my head fully around them but, at this point:

Derived Prefab

seems to be a better choice than using Variant Prefab widely and wildly.

Variant infers that it must differ from an original state, but it seems that's not a stipulation for a Variant Prefab being a Variant Prefab. Therefore it's, seemingly, more akin to what might be better termed a Derived Prefab, upon which alterations can be made, that don't go back up, or out to other instances, because it's a derivative and prefabricated.

At the point it's altered, a Derived Prefab becomes a Derived Variant Prefab, and even someone that doesn't know much about Unity can have a vague clue about it having a relationship up (Derived), but not out (Variant) and a personal origin story (Prefab).

Please feel free to argue with me on this supposition, as it will likely help me (and perhaps others) understand these things, and everyone find a better way to describe them, their purposefulness, usefulness and functionality.

 

Not sure why you would make a variant prefab without the idea being to modify it?

I haven’t used it yet, and I’ve only watched the video once, so i could be off base here, but it seemed straightforward to me...

(please correct me if im understanding this wrong)

Seems like nesting and variants are functionally the same. It’s just that choosing to create a “variant” creates a new prefab with the originally selected prefab nested as the only thing in the hierarchy. Where as if you were to just duplicate (Ctrl+D) the original prefab in the project window, it would make a completely seperate prefab with no references to the original at all. So any changes that you make to the original prefab would not show up on the manually duplicated (in the project window) prefab.

Creating a “variant” assumes that you’re “duplicating” this prefab with the goal to make unique changes to the original prefab, while still having references to all the rest of the changes you may make to the original. That way you can quickly create a unique variation of your original prefab in your project window but still have any changes that you make to the original also show up in the variant prefab (unless that property was overridden by the variant).

Anyways, mainly seems like a named way to quickly set up a nested prefab without having to drag your prefab into a scene, make it a child of an empty gameobject, then drag it back to your project window to make changes. Instead its a simple button press away~

 

Your last paragraph is exactly where the issue sits, if you're right. You've made a Prefab that derives from a "base", but not yet changed it, yet it already is called a "Variant", when it's not yet varied, nor are there any others of its type, yet. Hence my reasoning, it should be, at this point in time, simply known as a Derived Prefab.

But I, like you, am not yet certain I fully understand what the intended functionality is, nor the purpose of everything. And the word salads used to describe everything are off-putting. Decoding poor speech isn't a strength of mine. I struggle understanding things that are well expressed.

 

This is the point at which nobody wants to help you anymore.

 

This is the point at which I hope you'll eventually realise this wasn't about me, nor about others helping me. I'll battle through, in my own muddled way. I can make do. Thank you for your comment. Thank you for your previous personal assistance.

This remains about finding a better way to express what the new and improved prefabs are capable of, including their ability to be varietals, and the way in which descriptions and articulations have gone sideways, and down, and why, so a course correction might be made, to saying things better.

Since you've chosen to speak on behalf of others, I'll assume (for the sake of this bit of commentary) that you do. As I perhaps am, for another bunch of others, the end users not yet competent or wise in the ways of Unity or programming, nor able to disentangle spaghetti speech.

Prefabs are a cornerstone feature and defining attribute of designing, architecting and creating with (and using) Unity. On this, I think we can all agree. Prefabs 2.0 have been introduced at a seemingly arbitrary time, with a crucial key piece of functionality missing, after nearly a decade of demand and desire, whilst Unity is at a peak in its market presence, in a manner so poorly communicated that it's a mockable, laughable debacle.


If you're not finding humour in this, I'm sorry for you, the royal you, too. I strongly suggest trying to see the humour in this, otherwise it's just sad.

If you can't see that this could be done significantly better, and should be done better, or don't want to acknowledge these failings, or otherwise feel those responsible for word salad buffoonery should be beyond critique and questioning, then everyone loses, somewhat, eventually.

There is a disconnect apparent within the organisation. On the one hand, they value those using Unity creating wonderfully amazing and joyous UX experiences in AR and VR. On the other, they're not seeming to listen to those they hire to advocate for users in their own creation.

The world is a better place when Prefabs 2.0 are better presented, better communicated, better understood and (as a result) better utilised. You (the royal you) have to believe in games and game creation in order to be doing what you're doing with any kind of passion. Otherwise you're just taking a wage and none of this should bother you in the slightest.

You only get one initial launch of something as significant as Prefabs 2.0, and this has been botched.

The fastest and best way to create the best possible follow through (and the cheapest and fastest way) is to begin mastering the art of explaining the functionality, capability, expressibility and usability of Prefabs 2.0

To that end, and because you're well suited to and highly capable within Unity, and more of a writer than I'll ever be, why don't you (and the royal you) have a crack at articulating the strengths and benefits of Prefab Variants?

 

Well, you come in here, insult everyone, both users and Unity itself (and the developers and other people too) and then you expect what exactly?

Should we take you seriously after these stunts? There is the constructive criticism and there is the insulting behavior. My advice to you at this point to read up on the first one and maybe try again when you're capable of doing that.

I'm sure Unity people will force their grim to a smile and will try to answer you constructively, but luckily we don't have to.

 

Good for you, and the royal you, too

 

This makes a lot of sense, except for the bit where this is the single most prominent messaging and message being both sent and received and that's been so long desired and anticipated, teased and promised, and upon which the hype train is riding:



=====================

Prefabs 2.0

For anyone and everyone else not insulted by what I’ve had to say so far, you’ve probably realised what I’m on about, trying to find a way to clarify clearly, via the simplest possible articulation, the powers and potential of Prefabs 2.0

For those insulted or otherwise baffled by my approach, please consider the following, and attempt to do so with a little consideration for anyone and everyone not yourself.

Unity Worlds are populated by:

User created GameObjects with Components and Scripts, that can be bound up in a prefabrication process, to the project and external storage, making them portable between levels and projects, from which they can be instanced, referenced and edited.

This is part of why Prefabs are a big deal. They're the glue that binds within Unity work flows, across worlds both real and virtual. You and I know this, and innately think in these terms when conceiving of how to use Unity.

Further, Unity is defined, to a very large extent, by its Prefab Paradigm. It is either the best aspect of Unity, or one of its best.

Prefabs 2.0 are a huge deal because they change some of the processes of prefabbing, and remove some functionality, whilst gaining others, and are significantly more capable, perhaps orders of magnitude more so, because they permit nesting and traits.

One diversion from (or anomaly with) the pure analogies and metaphors of nesting are Variants (traits), because they mix the metaphors, being both reliant upon composition, but capable of providing some of the benefits of inheritance, and integrating within compositional creation of nested Prefabs in ways that are less than obvious.

Traits provide external depth and internalised width, nesting gives localised depth and externalised width. Prefabs 2.0 have a bit of both.

From one perspective: It's not entirely clear what problems this amalgamation of metaphors is trying to solve, or if it's just a side effect of the new structure of prefabs being sold as a feature to hide the loss of other abilities required to implement nesting. But neither matters.

From another: it seems nobody has bothered finding an easy way to communicate the capabilities of these mixed metaphors and paradigms of conception, design, creation, editing and utilisation. This is both suboptimal and risky, as it presents an opportunity for resistance to their adoption and/or utilisation, and less than ideal uptake and enthusiasm for them.

Especially when the initial noise is "NESTED Prefabs", note the capitalisation, that's what everyone is hearing!!!

But, back in the more moderate space, the bigger problem is that a lack of concise, elegant clarity dulls perception of potential, and that really slows down the excitement and enthusiasm possible from the release of Prefabs 2.0, which is a travesty.

Prefabs 2.0, despite what it may seem, are something I’m quite enthused by, as I’m coming from 3ds Max. There exists a similar set of capabilities, and conceptual and creational freedoms, thanks to the blend of Xrefs, instancing, referencing and the modifier stack.

Presuming you want to share these capabilities in the best possible way, to the largest possible audience, for the easiest possible adoption and greatest possible enjoyment and empowerment, I'm both criticising the current communication of these things, and attempting to find ways to think about them clearer, so they can be articulated better.

Discovering that someone's well aware of the power of traits, and only using caPitalisation cHoices to deliver the message is more concerning, not less.

 

Ok, this has gone way off topic, the original question has been answered, the rest is just kind of directionless ranting about naming. Since this beta, things are subject to change, and things often change from original announcements. The terminology has been explained and appears to be understood by most. These forums are for feedback on the features themselves not arguing about naming. Those points have been noted by and continued arguing about it isn’t productive. Closing.