Testing various import flows, and this is an error (similar) I've run into several times with glb a
Testing various import flows, and this is an error (similar) I've run into several times with glb and gltf files. I assume the issues are with the exporting programs, but am curious if this is something we can catch and assign (looks like it may have to do with scaling)
is not valid. Input localScale is { Infinity, Infinity, Infinity }.
13 Replies
How do I change the name of the Panel Manager element?
I'm trying to have the testing panel appear in floating in the world when clicking play and to be able to drag it and interact with it (i.e. goal is to have a start menu), but I keep getting this error despite following the Adding a New Panel documentation in the Open Brush Docs
Brush Editing
Status (working from memory, putting these notes where they can be found)
I haven't been using the brush modification branch for quite a while, as it hadn't been updated in quite some time.
Wasn't sure if it would get picked up on, so basically just using what I build in unity (which is unfortunate, because the brush editor tool is much faster to work with)
If it's been recently updated, I'd be happy to take another look at it.
They specifically want to work on shaders, which complicates things. As it's not at all clear where or how to register the enums so they are recognized.
This caused problems on export, although I think I was able to film with them (if that didn't break at some point, would have to dig things out).
Do know that at one point I was able to film these, and I think development might have stopped about the same time we were having general camera issues.
If I recall correctly, there was a pathing issue or similar disconnect where the exporter didn't know where to find the externally created assets correctly,
so it couldn't package them into the exported file.
Enumeration of some sort might also be an issue. I think to get things working at one point I had to place all the key value pairs directly in the code as a dictionary. I'm assuming there's a more elegant way to do that.
Custom shaders had problems for similar reasons, although I remember seeing something in the toolkit that suggested there might way to add them. [It's been a while, since it's a bit muddled, but if there's an update I'd be happy to check it, since we'd want the most currently relevant information] I was able to get all or most of the base brushes working. (not including the foam brushes). Some of them had pretty limited exposed parameters, so there wasn't a lot you could do with them. I think Keijiro had some issues when modifying, and the drafting brush couldn't be modified. Pretty sure I was able to get everything else to work or at least not break. : as far as practical suggestions, if work is resumed on this branch a way to drop textures in would be useful currently all textures have to be sourced in unity, so a user trying to make custom brushes in game is quite limited in what they can do, since there's not a whole lot of textures to choose from when modifying brushes
Enumeration of some sort might also be an issue. I think to get things working at one point I had to place all the key value pairs directly in the code as a dictionary. I'm assuming there's a more elegant way to do that.
Custom shaders had problems for similar reasons, although I remember seeing something in the toolkit that suggested there might way to add them. [It's been a while, since it's a bit muddled, but if there's an update I'd be happy to check it, since we'd want the most currently relevant information] I was able to get all or most of the base brushes working. (not including the foam brushes). Some of them had pretty limited exposed parameters, so there wasn't a lot you could do with them. I think Keijiro had some issues when modifying, and the drafting brush couldn't be modified. Pretty sure I was able to get everything else to work or at least not break. : as far as practical suggestions, if work is resumed on this branch a way to drop textures in would be useful currently all textures have to be sourced in unity, so a user trying to make custom brushes in game is quite limited in what they can do, since there's not a whole lot of textures to choose from when modifying brushes
Feedback wanted: https://github.com/icosa-foundation/open-brush/pull/588
GitHub
Don't include the _BackUpThisFolder_ButDontShipItWithYourGame folde...
We have no way to get core dumps from users in any case, so there's no need to save this. Until github's upload-artifacts fixes their slow performance, this should save about 5 minutes in u...
FYI: it seems that the manifest.json and packages-lock.json are changed at build time for the Linux and Pico builds, but not for any others. I didn't expect this; maybe it was obvious to others. I don't think it's particularly relevant, other than that I need to change the caching not to cache from these branches
https://github.com/icosa-foundation/open-brush/pull/595
GitHub
Only save PackageCache if it's based on the unmodified packages-loc...
The Linux build currently adds:
com.unity.sysroot
com.unity.sysroot.linux-x86_64
com.unity.toolchain.linux-x86_64
And the Pico build(s) add:
com.unity.subsystemregistration
com.unity.xr.interaction...
Is it Pico's code doing that or ours? I wonder if the linux stuff is harmless if left in other builds. i.e. does it "do the right thing' on non-linux systems?
linux hmm, that should at least be the same. what package is it adding?com.unity.sysroot
com.unity.sysroot.linux-x86_64
com.unity.toolchain.linux-x86_64
☝️
oh
it's probably fine to add those? I'll manually stick them in
annoyed about pico hard requiring xr interaction toolkit
they might end up with a forked mirror as well 😅
you can do it much better with asmdefs, like meta does
Slightly off-topic. Does the XRIT play nice with our stuff? Could we use any of it without having to change tons of things?
probably not, i haven't cared enough to try though!
Pico and Linux do it automatically; it's not something we do.
The packages I gave are from packages-lock.json; in manifest.json, it's less
(by "packages I gave", I mean the ones that are in the PR description)
pico depends on xrit which depends on subsystem, then i guess it's one of the linux-x86_64 that has the other two as dependences?