Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Opening some USD files can crash Kraken. #12

Open
Marti-S opened this issue Apr 17, 2024 · 4 comments
Open

Opening some USD files can crash Kraken. #12

Marti-S opened this issue Apr 17, 2024 · 4 comments
Assignees

Comments

@Marti-S
Copy link

Marti-S commented Apr 17, 2024

This bug usually occurs after a few times of opening different USD files.

Screenshot_2024-04-17_at_12 14 12
@furby-tm
Copy link
Member

furby-tm commented Apr 17, 2024

It appears this might be directly related to a missing asset that used to exist on your machine, which got baked into the (.usd) file upon saving from the DCC program in which saved it out, the file that it appears to be looking for is at the following file path:

/Users/marti/Documents/00_Afloat/AndorWorld/Characters/Assemblies/Alya/USD/Alya_SurvivalPants.usdc

However, the lack of this file existing should not typically correlate to a crash, and should therefore be fixed.

There are some issues currently when attempting to open some specific USD files with Kraken because I'm temporarily utilizing Apple's SceneKit.SceneView which offers quite a few limitations with USD.

I'm currently working on completely moving away from any of Apple's proprietary frameworks (fortunately this is the only one being utilized at the moment), now that I have all of SwiftUSD at my disposal, to provide a cross-platform open source alternative to Apple's SceneKit, (disregarding Apple specific API such as .scn and so fourth) by creating a more USD-oriented API design, which I expect to clean inconsistencies like this up.

@furby-tm furby-tm changed the title Open file app crash Opening some USD files can crash Kraken. Apr 17, 2024
@furby-tm furby-tm self-assigned this Apr 17, 2024
@furby-tm
Copy link
Member

furby-tm commented Apr 17, 2024

@stackotter Also I will focus on ensuring this open source framework alternative to SceneKit, (named HydraKit, which seems appropriate given its USD oriented approach) will work with each of SwiftCrossUI's backends, so that SwiftUI can be easily utilized in a same cross-platform way, example:

import SwiftCrossUI
import PixarUSD
import HydraKit

/**
 * A full UsdView-like application
 * that users can implement, and to
 * do so in only ~10 lines of code. */

@main
struct Kraken: App
{
  @State var stage: UsdStageRefPtr
  
  init()
  {
    /* setup usd plugins & resources. */
    Pixar.Bundler.shared.setup(.resources)

    stage = Usd.Stage.createNew("Untitled", ext: .usd)
  }
 
  var body: some Scene
  {
    DocumentGroup(newDocument: Kraken.IO.USD())
    { usdFile in
      HStack
      {
        HydraView(stage: $stage)
          .onChange(of: usdFile)
          {
            stage = Usd.Stage.open(usdFile)
          }
      }
    }
  }
}

The question there is should this be apart of the SwiftUSD package, or in its own?

Which especially for this use case, brings me to one additional nice feature improvement proposal for SwiftCrossUI, which is to implement an equivalent DocumentGroup(newDocument:) for that package (read more about this API here), it would definitely help for use cases such as these.

@Marti-S
Copy link
Author

Marti-S commented Apr 17, 2024

If I have a vote, I will vote yes for this proposal.

@stackotter
Copy link

I love the idea of HydraKit integrating with SwiftCrossUI, I've been waiting for an opportunity to figure out how 3rd party libraries can work with individual backends to provide new native views (and preferably without having to provide a separate target for each backend, but that may be the case for now).

The question there is should this be apart of the SwiftUSD package, or in its own?

I reckon it should be separate, no one's ever gonna find out about anything if it's all in the monolithic SwiftUSD repo.

Which especially for this use case, brings me to one additional nice feature improvement proposal for SwiftCrossUI, which is to implement an equivalent DocumentGroup(newDocument:) for that package (read more about this API here), it would definitely help for use cases such as these.

That would definitely be nice to have, but it'll require quite a bit of platform-specific stuff for things like menus and file dialogs so I'll need to add support for those to the 3 main backends first.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants