Meeting minutes
Monoscopic/untracked considerations for Model element #131
Brandel: we're looking for macos
… in stereo, the headpose is essential
… we have options on how to interpret that in monoscopic
… because you can see (??)
… there are 2 priorities and unclear what the answer is
… there's a good reason not to have transparent backgrounds in stereo but have them in mono
… I'm sure there are question
ada: is it worth having a bool attribute to say that you're exclusively monoscopic
… so you get the same behavior everywhere
bajones: in general, I'd say yes
… the idea that you want content reproduce the same across all medium is good
… users are creating something to say that the content is transparent
… having ways to opt in is great
… opting into transparent may force you into monoscopic
… if you set to monoscopic, maybe you expose more capabilities
… I'm in favor to opt into stereo or forced mono
… as you're scrolling up and down, the perspective will change
… you'll see it from seeing it from the top, to the bottom
… this effect can't be mimicked on a 2d screen
… it feels that this could be opted in in the future
… it's unclear if this is what developers want
… it might be easiest that the mono attribute is always mono
… having the fake perspective could be added later
… if there's camera control, it could be faked that way
alcooper: we already have model viewer that can do mono all the time
ada: I have to agree with that. These would be very similar
… the reason to use this would be convenience
… so you don't have to rely on heuristics
… in general, you give developers a less power model viewer
alcooper: it seems that mono doesn't give any benefits
ada: if you always set mono, you may as well use model viewer.
… having an element has benefit
alcooper: it seems this would add extra complexity with little benefit
mkeblx: why would this add complexity
alcooper: adding an attribute is something for developers to learn about
ada: yes because now you have 3 different rendering modes: stereo on stereo on headsets, stereo on 2d and monoscopic
… I'm more comfortable that we not add an attribute (?)
bajones: eventually we will need to add this forced mono
… but for now, it doesn't seem needed for the mvp
… if someone if you want just mono, just use modelviewer
… generally you use model for the stereo views
… I don't think we need to stress over adding this to the first version
… so now, you don't have transparent backgrounds and that's ok
… it's definitely a breaking change
Brandel: I have vision of (describes cool animation)
… if we get to a compositional arrangement, the transparent background case becomes less important
… I agree that we'll eventually get forced into this
mkeblx: it would be nice that you can force the mono behavior on a headset
… developers may want to do that
ada: even if we don't do it, it's ok to keep in mind that this may happen
Brandel: obviously, isometric is not the thing to do with model
… if we wanted to create a non-tracked model, the projection mode should be orthographic
… should NOT be orthographic
… are devs allowed to supply a custom projection
bajones: this doesn't sound needed for the mvp
ada: we may need to do it eventually and when we do, developers will do weird things with it.
… for different projections, devs should just use webgl
link to the meta presentation: https://
Spatial CSS Interest #91
<yonet> immersive-web/
bajones: this <spatial css> has been talked about for a long time, and now seems like the right time to start investigating
… would live to hear more about what ByteDance has done as well
… Have a lot more devices where this would apply.
… Biggest quetsions: How are safe volumes determined? How do things behave inside that?
… Lots of existing primitves on the web for spatial-ish transformations, but they're all focused on flat contexts, and we can't just suddenly start making existing Z-indices spatial
… though it'd be a shame to discard the existing work
… maybe an "opt-in" for "my Z is really spatial"
… no explorations myself would love to hear from those who have explored
cabanier: Did some early explorations at previous company.
… Definitely have questions about the volume and drawing over trusted UI
… need definitions so elements show up in the same way
… at least for chrome seems like they combine things in "3D" space and then flatten as the last step
… Questions about hit-testing/viewing back-face of elements
… Fallback is for browsers to just keep doing what they do today
ada: Backface-visibility is already a concept in CSS
<Zakim> ada, you wanted to talk a little to some of the questions posed
cabanier: Great, it's already solved then :)
ada: I have answers to a lot of this that I'll talk about later as well
… have been speaking with CSS WG folks about best way to standardize
… Incubations are done within CSS WG itself
… best path forward likely to have folks join the CSS WG and attend the relevant meetings rather than incubating here
… Need their expertise re: syntax, etc.
… open to other opinions on how to handle this though
… detached elements straight onto the 2D web doesn't feel like apprioriate starting point
… All kinds of diffuclty with bringing elements outside of the browser window when not in an exclusive context
… Things may need to be inside page for same reasons model needs to be inside the page; but eventually would want context to come out of the page
… proposing wider syntax for CSS later today, but nothing outside the window
… RE: building ontop of 2D web with auto-fallback
… this was where my initial investigations were, but it ended up not being interesting except for most basic use cases
… People will try to build more complex things which will immediately fail
… Working on proposal to establish a spatial context within the web
… e.g. an attribute or element such that children of that element get the new features and CSS behaves differently
… mostly proposing new ways to use exisitng CSS, not new CSS
Parth: Very interested in something like this. Particularly depth
… been working on a framework and developers have done cool stuff
… once you jump out of the plane, have to start thinking about interaction
… currently HTML can't support natural interaction in 3D space, so need to start thinking of that
… No gestures/spatial tracking, and is that something for this group?
cabanier: Good to hear your <ada's> presentation, but hope we don't have to do something completely new that doesn't work in 2D
… would look differently in 2D web
Ada: proposal is similar, but different
… some solutions are obvious and some have tricky bits
ruoya1: Very aligned with the work we've been doing, exploring extending 2D web content into spatial environment
… Really interested in Ada's proposal and making this happen
bajones: Expectations for how developers would use this, considering hte meta presentation with individual elements popping out of the page, is the expectation then that I would make my entire page one big spatialfigure?
Ada: Please no
… The goto thing folks think about is the most difficult thing to solve. I have thoughts that weren't part of this presentation, but there should be a way/simple syntax to do that.
Brandel: Some of this is similar to ByteDance's presentation.
… It's still fundamnetally a rasterized layer on the page, so negative parallax doesn't make sense
… second, it's a figure so it's been to be an individual figure and you're holding it wrong
Ada: Though people will definitely try to build whole websites out of it, and while I wouldn't be happy, we want to one day give them the right tools
bajones: Want to give folks "pits of success", and allow the first thing folks try to do with the API be hte right thing
… I can imagine the "Hello World" being popping the button out of the page
… But when the first thing that pops to mind is the thing ada doesn't like, that makes me go hmmm
Ada: Have to do negative to bring things out of page, and positive will sink into page
bajones: negative vs positive will also be a point of confusion, especially if any motion forward blits out of experience
Ada: I'll make a note to address that
bajones: Understand easy to push in and hard to pull out, but pulling out will be first developer experience/want
Ada: We do have a front limit that we automatically squash back if you go past
… but transforms will be clipped.
… (So this syntax works with 'front')
bajones: Still potential for developer confusion there, since it's not doing anything
… These seem like extremely powerful tools, and that's good, but it's easy to make very powerful tools that make the easy thing hard, and we already have that, it's WebGL/WebGPU
… What is the first contact developers will have with these APIs?
… sounds like Ada has given a lot of thought to this, but this is top of mind
Ada: From a standardization and implementation stand point, the route I'm proposing has "pop out of the page" somewehere in the middle of the roadmap
… Are you saying it's not worth without it? Or it's just something we should be aware of?
bajones: If it's an unfortunate reality that one of the first things folks do is one of the harder things to do, handholding would be appreciated
… e.g. to raise a button, you need to push the whole page in. It's not obvious at first thought, but maybe if you explain/handhold
Ada: The most correct thing folks could do would be to wait for hte right syntax
bajones: So expectation is that someday we will be at a point where we can lift things off the page
Brandel: First composable, spatial context, so it does still have to be rasterized, and I'd expect browsers to need a lot of work to become full-time stereo3D
Brandel: We see a good route to this to be that this is a good place to use it right
cabanier: Seems like the Meta and Apple proposals are fundamentally different
… we're essentially augmenting standard CSS, and you're building on/augmenting model to make a scene graph
… I worry that your proposal is going to be very different to specify, there's a lot of new rules and interactions to specify
… also feels like developers have to learn this
… seems overly complicated for what folks are trying to do, and I'm not even sure what the demand is for models to be broken apart
josh: from a designer POV, love the flexibility to incprorate WebXR flexibility into more of a style-sheet system
… one thing I am concerned about is inline
… Would love to se ethis be a place where folks who wouldn't otherwise build these experiences can use this to build them
… if there was some "simple" tag to do "levitate on XR capable device" that's the narrative I'd love to drive
Ada: That's the syntax for my whole proposal, but the concern I have is that building stuff that will have effects on the existing 2D web and will exclude the existing 2D web
… Need to add something to DOM tree, work out how much space you have in front, and can then work out what space you have
Brandel: If you do that today, then CSS compositing no longer works
… Things like background blur/shadow e.tc. no longer work
… These things will need to be done by a single unified compositing engine, which probably mean browsers need head poses
Ada: Looking at "What can we accomplish in a reasonable time frame" to get developers to experience the nuts and bolts of the spatial web
… initial proposal was way too much but was essentially the end vision
… this is something that's useful and can be built
… love to hear how feasible this is from other developers
… this is a pragmatic step to the future, and it's annoying that "the thing that should be easy is the hardest thing for everyone to do"
… from both an implementation and standardization perspective
Ada: This is our thoughts after a long time working on this
mkeblx: Obviously with WebXR it's kind of doing what you can do on Native and then bringing it to the Web
… Have spatial UI's in native apps, and what are folks doing with that?
… In VisionOS have front/back thing and that's likely what's giving you some ideas here
Brandel: Big challenge here is that SwiftUI is a greenfield compositor
… haven't convinced anyone to write a new web engine from scratch
bajones: No expectation/facility in native UIs to prevent user discomfort, but it's something we have to take account of on the web
… offensively bad looking webpages are fine, offesnively bad looking webpages that are also poking you in the eyeball are not
… native UI is free from constraints we have to consider
… lots of effort is going into placing other panels around a main panel, likely won't see an equivalent to that for the web
Ada: maybe we can talk about that at TPAC 2026 (... or 2027)
mkeblx: Example of text with composition/background blur being hard
Brandel: <p> tag is fully rasterized, and <span> would have proper CSS inside of it
… render with the full fledged render engine, and then all bets are off.
Ada: Floating shadow between model element and behind it not possible
Brandel: Input is a great question. It's elevated by a good input story, but doesn't mandate on
… can maybe raycast front glass and then vend as a 2D event, but can look into this in the future
mkeblx: Can't accurately pick then?
Brandel: Might be able to do raycasting to do so
mkeblx: Could do hover if not surfaced to the page?
Brandel: That degree of separation gives us options we haven't explored it
alcooper: I do echo a lot of Rik's concerns, I worry that there is this cool thing to do but it's too complex and I only want buttons to pop up. I see a easy way to implement that but apple's proposal is more complex and dependent on model being build.
Ada: I think it is still useful without 3D content, this is not a model feature but it is a web feature
<alcooper> m-alkalbani: Syntax makes sense to me, but question is about the workflow from modeling software to web
<alcooper> ... would artist need to essentially expose three separate models?
m-alkalbani: I think the syntax makes sense to me but my concern is 3D creation to web part.
<alcooper> Ada: yes, top case, bottom case, and hte model itself
<alcooper> m-alkalbani: Is this too much work for hte modeler? They can't just export one thing?
<alcooper> Brandel: It depends on how much you're trying to load
m-alkalbani: isn't it a complex thing to figure out for the developer.
Brandel: May need to elect in the tool multiple components to export
… so artists are used to it
… the alternative is bundling this all into a single file, but this is undesirable due to performance reasons, etc.
Ada: And developers would need to know how to/to look into the model (or worse unpack it into the DOM tree)
… initially liked having it in shadow dom, but have soured on that over the last few years
m-alkalbani: spatialfigure indicates to me that it's about one thing, and these examples don't seem to be that
Ada: There may be some things with multiple bits out there
Brandel: Apple Vision Pro had a website, it showed the vision pro, made out of a bunch of different pieces, which are removal
… the spatial figure would be for the entire thing, but each component is a "part" within it
… may want to have labels/localize labels, but it's essentially doing one job
… so maybe it is a scene, but it's a scene for one thing
… and eventually we'd have a spatial context that *is* a full page
ruoya1: Probably need some more time to digest, but from iniital impressions this is aligned with our static 3d container api features
… no conflict with other apis
… 3D model element is rendered behind the webpage and not pop out correct?
… We're interested in popping that out
Brandel: Given that entire content is a RealityKit scene in our impl, it's the kind of thing that could become independent, but going back and forth from web standard to 3d is complex
… no timing or proposal for that just yet
Ada: If we can get a more featureful spatial pointer we think we can pull an entire volume out of a spatial context
… this whole effort should work towards sitting things above the page (and letting pages know how much space above the page they have)
Brandel: A space completely independet from the page vs coming out of the page are two different things to think about, and the former is certainly easier
bajones: One of the best ways to affect adoptions of this is to make it so that some junior dev can come three weeks later and be like "Look I added 6 lines and made the page look a lot better"
… better to make it work with small tweaks rather than restructuring entire site
… concerned that's a huge barrier to entry
… swapping element types or adding attributes lets people trivially poke their toes into this ecosystem
… we're still targeting a small userbase, so large scale refactors won't be bought off on
… make the simple thing super simple
Ada: My intention is for the simple thing to be simple, it's just really hard to build and standardize in a way that works for the longterm web
… trying to be robust for the future
Brandel: Can definitely do that, just can't do it first
… Not sure there's a faster route that doesn't go through this
Ada: Is it insufficient to have "This is a thing that will take us there eventually, but we can't do the simple thing now"
Josh: Missing the clear simple onboard scenario
Ada: We're not hearing the thing that will make everyone jump up in their seat, we're proposing the thing that will give tools and make it simple in the future
Brandel: Pushing content into the page is 20 minutes, pulling it out of the page is a 2 million research grant and 5 years
… (xkcd reference, not literally)
Ada: want to try to prsent simple case
alcooper: Easier to get buy in on the thing more folks will use
Ada: If it's 10 years to get the simple thing regardless of if we expose this nuts and bolts, is it not better to expose the nuts and bolts as we go?
… also had to justify this, we're trying to build the spatial web, and this is the something we can get out there
… vs sitting on the thing for years, and breaking the web for everyone
<ada> coming back at 14:14
<ada> *14:15
mkeblx: RIP Daydream. :) Some people were thinking about CSS at that point. Anything there that can be pulled forward.
bajones: we had josh carpenter who did a lot of spatial web design work, in fact one of the slides showed one of Josh's illustrations
bajones: there were some interesting pie in the sky designs, I think that a lot of the spirit of those desires still lives on but what it lacked was any serious discussion of the mechanics used to enable it
bajones: it was about theorising about what kind of expdedriences this could enable but we didn't have too many discussions about this is the means we would take to get here
cabanier: Presentations talked about pushing things back but not pulling forward?
ada: Once we have full spatial web proposal, we should be able to do both. spatial figure proposal can only push back.
cabanier: So can it be transparent?
Brandel: No, it's like model. Can only be opaque. Can apply background blur for elements on top of model.
cabanier: So if the body of the doc has a color it wouldn't show through??
Brandel: It has it's own color, can change it to sync with page. Model has infinite space behind it, so not appropriate to texture.
ada: With spacial figure you could place an image in space.
Brandel: Had a bakeoff between punching through the page and current approach. People believed we needed to have compositing operations possible.
… It's pre-rasterized, so you can see pixels when you get up close. But it lets you reason about it in the existing web stack.
… Even if we did separation and rendered things on top we don't have an answer for web rendering/compositing. We either need to turn web compositor into a 3D thing or abandon principles used for things like background filter. Web is sRGB, moving to a different space like Vision OS would make it look completely different. Big ask for the platform
… to change full look to lift things off page.
cabanier: What if instead of breaking into multiple layers the whole browser window becomes a stereo display and renders left-right?
Brandel: Vision OS has so-far avoided sharing eye poses with shared-space apps. WebXR is not shared space. Would be possible to do that but would be analogous to what WebXR does today.
Brandel: Safari is a shared space app, can be up with other windows. WebXR hides everything. Model doesn't require exclusive.
bajones: How does model work today?
Brandel: Images are produced by a separate process and vended over IPC as a non-inspectable surface.
mkeblx: But you can still composite with it?
Brandel: Core animation can, Webkit can't.
… goal of Vision OS, broadly, is to avoid information disclosure that could be abused.
mkeblx: How much space do you need in front to be useful?
… If you only need a little bit of space pushing the content back solves problems.
Brandel: Yes.
mkeblx: If you can do model in a privacy concious way I can see the whole web working that way too.
ada: Full proposal supports that, up to browsers how to support. If you try to go beyond the bounds you get squashed unless you use transforms, then it clips.
… it's a thing we want to do and will keep advocating for.
Brandel: Two piece answer. From a technical perspective a stereo buffer can show negative parallax. Challenges with expanding things past the boundary of the rectangle.
… <Being an old person remembering the good old days> Wiimote Demo.
… content clips at the boundary of the container. But if people really wanted it you could do it with a stereo layer.
… It would mean trusted UI (Apple pay, etc) could be spoofed, since they show at a fixed distance from the page. They couldn't be clipped but may still fool people.
ada: Want to bring this to the CSS WG
cabanier: Shouldn't we resolve the issues we have with it first?
Brandel: Two concerns I have. web rendering compatibility and user comfort for elements coming off the page.
Joshi: My presentation wasn't really a "proposal", more of a thought started. Sounds like before we go to CSS WG we should have both the long term vision and the steps to get there.
<Zakim> ada, you wanted to say I don't think it's two camps
ada: I don't think we have two camps. What you want to have is exactly where I want to be, our proposal is steps towards that. Need to get approval to present the full story. I think if you only wanted to implement part of it that's something you could do. Hoping Lawyers give OK. Syntax is different from your proposal but shouldn't be too
different.
cabanier: I think we do have two camps. If you show your content in a non-supporting browser what would show?
ada: HTML elements would still show.
cabanier: I think our proposal needs far less changes to the web plaform
ada: I encourage you to write that down. I'll try to put together a more complete end-to-end proposal for what we presented.
… There's definitely work that should be done before we pursue either.
… both sensible approaches with pros and cons. And at the end of the day it's not our decision but the CSS WG.
cabanier: The already approved detached element previously and took it out due to no implementers.
Brandel: spatial figure won't hide HTML elements inside it in non-supporting browsers.
cabanier: But it'll look different.
ada: In our proposal you could implement only the detached element part if you wanted. Wouldn't be required to punch a hole in the page.
alcooper: Feels like we have a complexity inversion in the browser implementations. What you're saying is hard to implement seems easier in Chromium-based engines.
… Thinking about dev story, where eventually you want to build big things but start with something small. If we gave developers simple tools they may build more complex things with it. <Lots about doors and castles and towers here>
ada: Trying to propose a first step
alcooper: Will people want to jump over that first step, though?
Brandel: WebKit is already doing it.
Joshi: Is the reason the proposal seemed to hinge on model because you couldn't talk about the other uses either?
ada: Talked about model because it's an interesting use, but spatial figure is useful without model.
… 3D model has special cases like attaching to 3D parts, so it shows a bigger range of features.
Joshi: Feels like it sits outside what a lot of people want to do.
Brandel: Adding model is useful for driving forward more forward looking use cases. "Can I attach a sword to this button?"
… I should show more uses composed of exclusively 2D elements.
ada: One concern I have with my proposal is that if devs are excited by it they will do stupid things like putting the entire page in a spatial figure.
<Zakim> alcooper, you wanted to mention building proposal on model
ada: after seeing response to model I'm not as worried, but it is a potential risk
alcooper: If you don't provide a simple way to levitate a button you're incentivizing the bad behavior you talked about.
… Understandable that you focused on model so much, but my reaction is "we don't even have model so this must only apply well down the road."
ada: I need to re-write the approach. Not mutually exclusive with model. Model is a reduced case of a spatial figure, but model was built first and we're taking lessons we learned from it.
alcooper: Can you do some of these things with model alone?
ada: I've hacked together demos with it, but it's not pretty.
alcooper: Can't you swap textures?
Brandel: Not with USDZ, which is like GLB. Monolithic file.
… <Shows a demo, notes that it's not a proposal>
ada: Encourages cabanier to do a deeper dive on their approach.
cabanier: Feels like your approach is based on OS primitives which we don't have
Brandel: We pushed to create these primitives in the OS.
ada: We didn't give much thought to how native works when designing. Designed web-first and then showed the native engineers. spatial figure is the step that gets us to the point where we can get web devs looking at the syntax before it settles into a full spec that latches onto the rest of the web platform.
Brandel: We would encourage folks to talk to their compositor teams. We were shocked at how hostile they were to our initial proposal.
<Break Time>
More expressive syntax for environment map #132
immersive-web/
ada: we've covered some of the ideas here, but this proposal was precipitated by some very scary experiments by creative technologists:
… stacking several models and using alpha-blending to manage light-blending. It's by far and away the most expensive way to manage a need that many people would like to try
… It would be good for environment map to be able to blend lights properly, to allow different formats, and potentially different projections (cubemap vs. equirectangular, or even Spherical harmonics)
… CSS gradients, other procedural methods for generating lighting. We initially proposed it as an HTML attribute because <model> was such a constrained use case for augmenting CSS with new syntax
… however, if we have <spatialfigure> or material CSS (shiny H1s etc), they would have need for an environment map, and that makes it worth pulling into CSS as a responsibility
bajones: something in the previous presentation suggested to me that a page should have an environment map. Is that a derivative of this?
ada: That's related to website environment/spatial backdrop as well
bajones: That made me think that setting a global env map might be a good thing to do on a page, and pushing that into CSS seems natural to me - overriding is good, but a decent foundation for setting things to be the same.
… Understand why your CSS folks would strive for economy, but checkbox has a number of bespoke actions as well
… this seems like it belongs in CSS if it flows between places
… it's a lot like background-image
ada: yes, and syntactically, I'm looking at things that look like that
… <picture> has https://
… blending would be additive rather than source-over etc, but there are good reasons for specifying that
cabanier: you don't like it being in HTML because you want to add more information?]
ada: Yes, like `poster` it's under-specified, in terms of things like format and blending. We should retain what we have, but adding more functionality in a place where it can grow would be good
cabanier: we could grow it the way it is, couldn't we?
ada: yes, we could add key-value pairs, but it feels cumbersome
cabanier: are there places where only one element uses a CSS attribute?
ada: possibly not - but in a world where we want to to want to let people light more things, this is a good home for it
bajones: supporting light and dark mode is a good, simple place to justify this - it'd be possible to do it declaratively in JS, but there's a lot else about CSS that manages this "for free"
ada: if people can come up with other good arguments for doing this, it'll help justify the work
bajones: can you explain more about using multiple maps?
ada: it can be for blending, or using different lights in different parts of the scene
Brandel: having more control lets authors manage blending, _and_ local lighting
bajones: There's not a place in the web that's quite like this today
… you can use the environment map _as_ the background for the element and then additively blend them, but it's a different path to uploading these things for being cubemaps.
… you could write a shader for doing it that way, but the compositor isn't going to benefit from it
mkeblx: There are some single-element CSS attributes like caption, but it's rare
alcooper: there are a lot of things that people _used_ to do but no longer want to let new things in
ada: yes, we've had that input a number of times
… maybe we hold off on this until we need to use it on other elements as well
mkeblx: background image can stack multiple images, but it's not currently additive
ada: It could have environment-intensity, and a y-axis heading rotation etc. (rotating on Y is easy, the rest is scary)
mkeblx: could you overload some of these things to behave differently for model? Could we use background-image instead?
ada: if there's a world where we _do_ set env map on arbitrary HTML, we may want to do both background color and env image, but it's not clear whether we'll get there
mkeblx: How would we be able to work with format concerns?
ada: yes, image-set() provides a path to this
mkeblx: I would like to have the kind of control this proposal provides
ada: I like this because the single-attribute has a bad code smell
Brandel: to echo Brandon there is a risk of exposing something that is intractibly difficult but syntax that makes it seem like you can do more environment maps than the system can handle would lead to developer confusion
mkeblx: How does Apple look at ideas and problems like shadows?
ada: I think there's a lot of implied complexity about the lighting environment, like where they are and how sharp they are, that aren't adequately understood simply by virtue of having an IBL. It seems like it might be a while away from being a showstopping problem
mkeblx: Okay - what about a model element? when it's extracted from the page?
Brandel: I'm not sure whether we know enough to figure out where to orient and direct light
bajones: ARCore hallucinates a cubemap and an "estimated primary" light source so that drop-shadows can be computed
… it could be inferred from an IBL, but I'm not sure of the quality you'd get
… But that's the sort of thing that may need to be standardized, which can scare lawyers or jeopardize the predictability of rendering
… it might be better to expose that to the author, to say "here's the prime light vector, intensity and color"
ada: would you like to file an issue for it?
bajones: I'm not as concerned with it in the page
… I can see that people might ask for it - not sure it's required for MVP, but they'll want it
<general realization that this tumbles into all the full game engine feature set>
bajones: we _can_ do this, but have to check whether this ends up being the <unityengine> element
bajones... Maybe we let people stack ten models and suffer the consequences before immediately accommodating a piece that blows it up
… touching JS for this is not ideal, but in a balance-of-harms discussion it might be the less worse
ada: I think I won't push on this, but feel like it might be a useful part of a fuller proposal
… It would be more useful in a world where it applies to more elements
<cabanier> https://
<atsushi> cybernetic avatar intdocudive video