You might be able convert gltf to usd using some Apple content tools AFAIK. ModelIO is what you want to use for loading or creating models. But ModelIO removed fbx support, so now you have to use tools to convert fbx to usd which is quite lossy (f.e. losing all textures, etc). Or there are open-source fbx processors.

Just to clarify the os_log_with_type works from a .cpp, .m, or. mm file. But if you try to pass a dso handle from a .m, .mm, or .cpp file that is not Logger.cpp or Logger.mm calling my_os_log_with_type, then that &__dso_handle has some sort of protection that doesn't generate any file/line in the new Console.

Hey Quinn, That’s not the way apps/reality works. Okay now my log is 4K characters, and os_log truncates at 1k. Or I need to route errors/warnings to a FILE*. Or I need to filter out specific messages. Or I use fmod or any number of commercial game libraries, and they just supply a callback hook with level/file/line/func/message. Or I need to print thread name and suppress the os_log output to console that only has TID:PID both of which are not human friendly. We can’t just inject os log macros throughout all this code. Every system already has its own logging system and os_log thwarts routing logs. os_log even reports the call location and timestamp which isn’t passed down. See android_log_message for a way easier and more flexible log call. A single code point under a mutex can hand it level, group, file, line, message. We’ll just stick with printf, but is there someway we can feed the console all the log fields we have without going through the severely limited os_log?

Not exactly. I thought you might know of a new api to talk to the Xcode console. I’m just trying to pass a dso handle from existing log macros to a central existing C++ logger and get the console to print file/line. Seems simple enough if these calls don’t take file/line/func explicitly. Apparently these calls use the return address to find the caller, and don’t allow that to be passed down. That’s why the calls have to be injected at the call site. I’m not sure what the dso_handle is for, but must be to quick filter out libraries that Apple wants to hide logs from. It’s just a mach_header which is only .o file and not line specific. This log system was always built for Apple to use internally, but pretty much impractical to use by anyone else. But it’s all I have access to. But I’ll file something.

Also finding that our ancient syslog calls are just going out to the console even without an openlog call. And there's no API to test if syslog is open or not. So I'll remove that code too, and just go to printf. But I'd like to use os_log solely for the file/line jump. But I need to be able to call __builtin_return_address() and hand that (and the dso_handle?) or file/line/function to the logging system. Being unable to send all logs to a central point in my game code, and do filtering, and locking a mutex, and breaking up multiple os_logs, and supplementing additional data that each macro doesn't is important. I can't do this in Swift, ObjC, or C++. There is no viable log call using NSLog, syslog, and os_log_impl since these all appear to call __builtin_return_address(0) internally. So that forces these Apple specific calls to be injected into all sorts of code that doesn't need that to get the correct file/line.

https://feedbackassistant.apple.com/feedback/13203125

You're supposed to just run each algorithm per row, and then take the smallest one. There's little point in using one algorithm for the entire image. PNG lets you store the lossless algorithm type as the first byte of each row. I've always used my own png code instead of Apple's.

These are errors. And I have warnings as errors on as well. And also xcode reports stale errors in the issue list. The app should not have launched. This is a workspace building several projects into an app, but it’s like Xcode doesn’t care if one of the projects fails. And sometimes it cares about errors that were already fixed until I “clean build folder”. This is mostly a C++ lib linking to ObjC++.

You are precompiling shaders to a specific metal version, and then that should be compatible with all newer versions of Metal and MSL. There are support checks, and availability macros and weak symbols so you can call ahead to newer functionality but have a minspec for iOS/macOS.

spirv-cross MSL output is converting SPIRV IL which is completely different than the MSL that will result from DX IL conversion. You have to pick whether you want debugging of quite unreadable transpiled MSL from spirv-cross with all comments stripped, or whatever shader converter generates (probably not even debuggable MSL). HLSL -> DXC -> DXIL -> metal-shaderconverter -> metallib (containing Metal IL)

Seems this isn't supported. So then would need to ship loose-packed metal files in a bundle or archive them myself.

SwiftUI focus doesn't make any sense to me either. I'm just trying to have keys route properly on a NavigationSplitView. The detail view is a WKWebView and can respond to most keys, but then the list items don't advance off up/down arrow. And the web pages cmd+S (search) doesn't work if the listView is the focus. So the whole firstReponder model really doesn't work. I'm happy to always focus the WKWebView, but then I need the arrows to advance the list without the error "bonk".

I'm not writing Natvis presently, but I have written some in the past. It was EASTL that has the natvis file for all of it's STL data structures. And Xcode has hidden away all of their STL visualizers in fast C++ land, and stripped all the python. And I've also had to write lldb python to fix debugging some of my C++ structs. Both are painful, so no one writes them or puts them out on GitHub. But I feel like the more options that Xcode can import the better, and natvis seems to have won. If you can point me to anyone doing lldbinit files for their projects then I'd be surprised. Will write this up as an FA post.

You are sending an srgb format and specifiying a linear colorspace. bgra8unorm means the data is typically stored gamma space. bgra8unorm_srgb converts to linear on reads and would match your color space.

So in 4 years, still don’t have functionality of a basic NS/UITableView. Seems there is time to add massive new features but not fix the basic one here. Have a NavigationSplitView with a List, and keyboard commands to advance the list when the list is collapsed or not. When not collapsed the selection happily scrolls off screen which is not acceptable. Arrow keys properly scroll the list to the selection, but that is built-into List. Looks like I have to rewrite to a (limited to 10 item VStack, ScrollView, and ScrollViewProxy) as a workaround. But my list is a flattened list of files. How about a List.scrollToSelection() call? No Apple samples of a real basic UI using SwiftUI, just recipe books with fixed count elements.