Exporting then Importing from Sketchfab
So I am currently in a project with 3 other people at the WMC. I'm currently trying to figure out the best way for everybody to be sending their assets to me so I can then put it all together for our project!
The way I have imported the following 2 assets, the forest i drew, and the druid from the library (only for testing!) is by using Side Quest and ripping it straight from the headset. However it would be much easier if my team could send me their drawings via cloud, so we tried Sketchfab! However whenever i try and upload that .glb file, or any of the other formats on there, they will give an error (the untitled/flower files from the right windows).
I am using the Sdk:) I am still new with Unity so I'm bad at explaining it properly, super sorry!!
44 Replies
This is about to get much easier - what's your timescale?
may i ask what a timescale is 🥲 is it a unity term or do you mean for our Project in general? hahah sorry!
We'll be launching something soon that will make this much easier. do you need this now, in a week, in a month?
We started our project in November and the technical finish date will be at the end of February! However we will start asset creation this week:)
A week would be ideal, but we can also try and organise ourselves and use sidequest too! its just a lil more work hahah
I wouldnt wish to bother you too much just for us!
a week. that's probably a bit too soon
ok.. next question - sketchfab.
can you share a link to the upload with me
yeah illl share it now! its awful though hahahah, its the first thing i drew so dont judge me! 🥲
i want to check something
DM me if you prefer
is this an error only for me, does sketchfab work for others? I've tried on two different machines but with the same result
not sure. just looking now
@Keroxsi - can you try using this package?
i got these errors on import of it
im using unity version 2022.3.32f1, should I use Unity 6 instead?
the glb files (from headset) show up on my older sdk, but as blank on the new sdk
confused. i thought the older sdk was totally broken?
oh. "from headset"
not from sketchfab
gotcha
@eerop you've introduced a dependency on Unity Mathematics into the Toolkit/SDK
Is that intentional?
I know. It was on my todo list to add to the toolkit readme to install burst/mathematics, but I just realized I forgot it
Is that for Burst/Jobs support?
yes
@andybak is it ok if we tell people to install Burst and Mathematics in the install instructions here: https://github.com/icosa-foundation/open-brush-toolkit/releases/tag/v24.0.0#:~:text=experimental.unitypackage%20instead.-,Newtonsoft%20errors,-If%20you%20get
@Keroxsi in the meantime - just unzip this and open it as a unity project:
There should be a way to declare dependencies for a .unitypackage. I'm sure I've seen something about that.
I wonder if the easiest thing is to move the burst jobs stuff into an optional extra.
either another package or another repo or something.
well the split mesh by stroke tool uses it heavily, so it would require rewriting it to work without burst and jobs (which is hard to optimize). I don't see a problem with just telling people to install burst. Except maybe it's not good user experience that when they open the project for the first time they get a bunch of errors.
i meant "move the new features that require Jobs into a separate thing"
a lot of people who use the core functionality in the toolkit/sdk aren't regular Unity users - so making it more complicated is bad
the install instructions are already a bit too complex!
so something like the toolkit for urp? https://github.com/kijai/tilt-brush-toolkit
that's not the toolkit for urp
someone else made that and it's out of date
there's a link to it in the readme: https://github.com/icosa-foundation/open-brush-toolkit#:~:text=This%20fork%20has%20URP%20support
oooops
this is the correct instructions: https://github.com/icosa-foundation/open-brush-toolkit/releases/tag/v24.0.0
that points to:
https://github.com/icosa-foundation/open-brush-unity-tools
Yeah I'm fine with that. So the goal is to make it so that these errors don't show up in the default installation, right? Then I think it would be fine to put it in a feature branch.
It's the unitypackage most people use. So it's nothing to do with branches.
If we can declare dependencies in a unitypackage then that would fix it too. I'm just aware that we're spending a lot of time fixing the old sdk/toolkit which is meant to be in retirement!
Damn thing
If we can declare dependencies in a unitypackage then that would fix it too.i did some searching and i don't think it's possible for .unitypackages, only for upm
(sorry to butt in! is this project only to be opened in ver2019 or is 2022 okay also?)
This file works for .glb files from Sketchfab by the way, thank you!! ❤️
2022 should be fine
this might give a clue:
https://openupm.com/packages/com.needle.upm-in-unitypackage/
it's talking about something slightly different but it might do what we need
GitHub
GitHub - needle-tools/hybrid-packages: Export UPM packages as .unit...
Export UPM packages as .unitypackage files. Contribute to needle-tools/hybrid-packages development by creating an account on GitHub.
sry forgot to reply, but thanks for sharing this. I'm busy with a CS course right now, but i'll try to get this done by this or next week.
@andybak does there exist a unity publisher account for Open Brush already?
the thing above requires one
@mikesky ?
I think I did set up one, I’ll dig it out/make one if not tomorrow
We have an org for our keys so it’ll be tied to that
The asset store does allow upm package uploading now, but instead of using scoped repos it goes in as an embedded package
so I think it'll work if we create a UPM package containing the jobs/burst code, then make it a .unitypackage using the hybrid packages above.
I'm creating the UPM package right now. This is probably ok for the package.json right? In terms of the name and description and stuff:
i also need to set the dependencies
I'm trying to remember why we don't make the whole thing a UPM package. The original reason for sticking with unity packages was because I didn't want to put effort into the old toolkit that I could spend on the new unity tools.
But now we seem to be spending time anyway? So is there a reason not to go full upm? Is it more work than whatever you're doing for this hybrid stuff?
It's a shame the new unity tools isn't closer to the finishing line. I mean it's pretty close but...
Yeah, this! there shouldn't be any reason to not go full upm 😄
I guess I was just hoping hoping that the old unity SDK was just in maintenance mode now. 😦
im fine with that. i'll get this done and then if I wanna do something in the future I'll do for the unity tools. I wanted to do this because if someone downloads the .unitypackage for the UnitySDK there's the errors with burst and mathematics.
Only if we include your new stuff in the unity package . The current unity package is fine and we could always make one that excludes the new stuff.
People who are technical enough to know how to use the new things you've done will probably be technical enough to download the unity project
I don't know - in some ways I've kind of lost sight of the bigger picture here. I'm trying to hold too many different things in my head at one time
I can take care of this, you can focus on other features
@andybak
ok I figured out a way for us to win here.
What we achieve:
- the unity-sdk can be turned on to maintenance mode, so any future development (except bug fixes) will be made for the newer unity-tools
- the feature I developed "split mesh by stroke" is easily installable by a new user who installs the unity-sdk's latest release, as a UPM package.
Plan: (do these 2 steps)
(1) merge this new PR into main: https://github.com/icosa-foundation/open-brush-toolkit/pull/13. It has been tested by me to work on a fresh unity project.
(2) Modify the latest release README here or make a new release: https://github.com/icosa-foundation/open-brush-toolkit/releases/tag/v24.0.0
To include a new section:
Sounds perfect!