I have created a 3D model of a local outdoor performance space and I have an app that usesMetal on MacOS 10.14.2 to display the model. I want to create an animationby flying the camera around the scene, while record each frame. I know how to dothe animated fly-around and I know how to create a video frame-by-frame withAVFoundation. The step for which I can find no information is how I can capture each frame.I have a completion handler so I know when the gpu has finished each command buffer.But what is the best way to get the image in space?I thought perhaps I could do this by attaching a second texture to colorAttachments[1]but this has resulted in some odd behavior where the original scene that used to fill myMTKView window now occupies just the upper left quadrant of the window.What I was trying to do is write the same color to both colorAttachments[0] (my screen) and tocolorAttachments[1]. In my shader I defined:struct FragmentOut { float4 color0 [[ color(0) ]]; float4 color1 [[ color(1) ]];};My fragment shader looks like:fragment FragmentOut grove_fragment_function(VertexOut vIn [[ stage_in ]], constant Uniforms &uniforms [[buffer(1)]]) {....float4 color = diffuseColor + ambientColor + specularColor; out.color0 = color; out.color1 = color; return out;}My hope was that I could then use something like:offScreenTextureBuffer?.getBytes(buffer, bytesPerRow: 4 * w, from: MTLRegionMake2D(0, 0, w, h), mipmapLevel: 0)to transfer the image data to a local buffer.This doesn't seem to work, plus I have the unexpected display behavior noted above.I am configuring the offScreenTextureBuffer thus:let pixelFormat = MTLPixelFormat.bgra8Unorm_srgbvar offScreenBufferDescriptor = MTLTextureDescriptor.texture2DDescriptor(pixelFormat: pixelFormat, width: 1000, height: 600, mipmapped: false)offScreenBufferDescriptor.usage = [.renderTarget, .shaderRead]offScreenTextureBuffer = device.makeTexture(descriptor: offScreenBufferDescriptor)
Post not yet marked as solved
Is there a Swift equivalent of NetFSMountURLSync that throws instead of returning an error code as an Int32?
Or is there a better function?
I have this working, but it would be nice to get more information returned than just a numeric error number if the mount fails.
I have an NSTableView which shows the longitude and latitude points of objects on a map. Some objects, like trails, have many rows in the table. When I change objects I want to update the NSTableView and then select row 0. I tried [obectCoordTable reloadData]; [objectCoordTable selectRowIndexes: [NSIndexSet indexSetWithIndex: 0] byExtendingSelection: NO];This does not work because reloadData does not reload the table. It only schedules a reload for some time later(on next iteration of Main Loop?). So my attempt to select row 0 happens first. Then just before the tabledata are reloaded a (void)tableViewSelectionDidChange: happens with selected row reset to -1. So myselection of row 0 is ineffective.How do I select row 0 after the reload is finished? There seems to be no delegate method to notify the userwhen a complete data reload is completed.Do I have to schedule the selectRowIndexes for execution at a later time and hope it is after the data reload? That might work but seems a bit too hokey?Thanks.Richard Stover
I would like to draw text along a complex bezier curve. I've seen several examples on the web using CGPathApplyto do this. But those examples seem to be wrong. CGPathApply does not supply you with a series of points alongthe curve. I just get back the points, and control points, I just used to specify the Bezier curve. I want actualpixel coordinates of points along the curve. Is there some way to do this? Do I have to write my ownfunction to reproduce the Bezier curve points given the end points and control points? Has Apple documentedexactly the algorithm they use for doing this? Or is there some CG function I have overlooked thatdoes the evaluation for me? Or is there a CG function that takes a string and a path as arguments anddoes the job for me?Thanks.
Post not yet marked as solved
I posted a problem on the MetalKit forum yesterday. It involves an interaction between ModelIO, MetalKit,and wavefront material file data. I wondering if someone familiar with the inside details of ModelIOmight be able to take a look at my post and provide some suggestions to the questions posed.Thanks.Here's the post:Using wavefront mtl file to define vertex color
Post not yet marked as solved
I have a wavefront model obj file with over 100 objects, each specified by a line in the file of form: o object_nameEach of the objects appears as a submesh when imported with ModelIO. However, thesubmesh name property is blank and not set to the name of the object as given in thewavefront file. I can't find any other property that might contain the name.How can I get the object name from the ModelIO data?Thanks.
Post not yet marked as solved
I am developing a MacOS program using MetalKit and ModelIO. The ultimate goal is to use the modelto analyze the acoustic properties of a performance space. Initially I'm just creating a visualimage of the space (stage, walls, seating, etc). I create a wavefront file (.obj and accompanying .mtl file).I can define the vertex color for every vertex in the .obj file. But I would like to use the Kd propertiesof the mtl file to set the color so that specific colors are associated with specific named materialsin the mtl file.I use ModelIO to create an asset and then extract both the model mesh and metal mesh:// Extract both the MetalKit meshes and the original ModelIO meshes var meshes: (modelIOMeshes: [MDLMesh], metalKitMeshes: [MTKMesh]) meshes = try MTKMesh.newMeshes(asset: asset, device: device)I see all of the mtl properties for all of the 147 submeshes in the imported model.If I specify the vertex colors in obj file then I see all of those colors in the 147 metalKitMesh submeshes.But if I do not specify all of the vertex colors in the obj file then all colors in the metalKitMesh submeshesare Black (0,0,0). The colors specified in the mtl file are ignored.The primary question: Is there a way to use the mtl colors to automatically set the metal submesh colors?Secondary question: In the more general case, what is the best way to convey all of the metal parameters tothe shader?Thanks
Post not yet marked as solved
The ply model file below illustrates a problem which I think may be an issue for ModelIO.If you save to a file and then add the file to a new xcode project (10.0 beta 6 or 9.4.1 show same issue)you will see a simple figure. BUT, note that the number of faces is shown as 25 (the line: element face 25). The 25th face actually has 0 vertices.That is the last line of the file with just one number: 0.This 25 count is a hack to the original file and a workaround. If you change the face count to the number of real faces (24) youwill see that the 24th face is missing from the figure. You don't need an app to see this issue because it shows up in xcode.But I have a Metal/ModelIO app that displays this figure and that app shows the same problem. The last face is always missing.Any ideas what is going on?-------------- data file starts on next line (save it to test.ply)plyformat ascii 1.0comment Created byelement vertex 72property float xproperty float yproperty float zproperty float nxproperty float nyproperty float nzproperty uchar redproperty uchar greenproperty uchar blueelement face 25property list uchar uint vertex_indicesend_header-5.0 0.0 0.0 0.0 -1.0 0.0 255 0 0 comment 0 back t05.0 0.0 0.0 0.0 -1.0 0.0 255 0 0 comment 1 back t05.0 0.0 2.0 0.0 -1.0 0.0 255 0 0 comment 2 back t05.0 0.0 2.0 -0.0 -1.0 0.0 255 0 0 comment 3 back t1-5.0 0.0 2.0 -0.0 -1.0 0.0 255 0 0 comment 4 back t1-5.0 0.0 0.0 -0.0 -1.0 0.0 255 0 0 comment 5 back t15.0 0.0 0.0 0.89442724 -0.44721362 0.0 63 8 32 comment 6 right side t07.0 4.0 2.0 0.89442724 -0.44721362 0.0 63 8 32 comment 7 right side t05.0 0.0 2.0 0.89442724 -0.44721362 0.0 63 8 32 comment 8 right side t07.0 4.0 2.0 0.89442724 -0.44721362 0.0 63 8 32 comment 9 right side t15.0 0.0 0.0 0.89442724 -0.44721362 0.0 63 8 32 comment 10 right side t17.0 4.0 0.0 0.89442724 -0.44721362 0.0 63 8 32 comment 11 right side t17.0 4.0 0.0 0.0 1.0 0.0 127 16 64 comment 12 right-most front t04.5 4.0 0.0 0.0 1.0 0.0 127 16 64 comment 13 right-most front t04.5 4.0 2.0 0.0 1.0 0.0 127 16 64 comment 14 right-most front t04.5 4.0 2.0 -0.0 1.0 0.0 127 16 64 comment 15 right-most front t17.0 4.0 2.0 -0.0 1.0 0.0 127 16 64 comment 16 right-most front t17.0 4.0 0.0 -0.0 1.0 0.0 127 16 64 comment 17 right-most front t14.5 4.0 0.0 0.70710677 0.70710677 0.0 191 24 96 comment 18 right front diagonal t02.5 6.0 0.0 0.70710677 0.70710677 0.0 191 24 96 comment 19 right front diagonal t02.5 6.0 2.0 0.70710677 0.70710677 0.0 191 24 96 comment 20 right front diagonal t02.5 6.0 2.0 0.70710677 0.70710677 0.0 191 24 96 comment 21 right front diagonal t14.5 4.0 2.0 0.70710677 0.70710677 0.0 191 24 96 comment 22 right front diagonal t14.5 4.0 0.0 0.70710677 0.70710677 0.0 191 24 96 comment 23 right front diagonal t12.5 6.0 0.0 0.0 1.0 0.0 255 32 128 comment 24 front t0-2.5 6.0 0.0 0.0 1.0 0.0 255 32 128 comment 25 front t0-2.5 6.0 2.0 0.0 1.0 0.0 255 32 128 comment 26 front t0-2.5 6.0 2.0 -0.0 1.0 0.0 255 32 128 comment 27 front t12.5 6.0 2.0 -0.0 1.0 0.0 255 32 128 comment 28 front t12.5 6.0 0.0 -0.0 1.0 0.0 255 32 128 comment 29 front t1-2.5 6.0 0.0 -0.70710677 0.70710677 0.0 63 40 160 comment 30 left front diagonal t0-4.5 4.0 0.0 -0.70710677 0.70710677 0.0 63 40 160 comment 31 left front diagonal t0-4.5 4.0 2.0 -0.70710677 0.70710677 0.0 63 40 160 comment 32 left front diagonal t0-4.5 4.0 2.0 -0.70710677 0.70710677 0.0 63 40 160 comment 33 left front diagonal t1-2.5 6.0 2.0 -0.70710677 0.70710677 0.0 63 40 160 comment 34 left front diagonal t1-2.5 6.0 0.0 -0.70710677 0.70710677 0.0 63 40 160 comment 35 left front diagonal t1-4.5 4.0 0.0 0.0 1.0 0.0 127 48 192 comment 36 left-most front t0-7.0 4.0 0.0 0.0 1.0 0.0 127 48 192 comment 37 left-most front t0-7.0 4.0 2.0 0.0 1.0 0.0 127 48 192 comment 38 left-most front t0-7.0 4.0 2.0 -0.0 1.0 0.0 127 48 192 comment 39 left-most front t1-4.5 4.0 2.0 -0.0 1.0 0.0 127 48 192 comment 40 left-most front t1-4.5 4.0 0.0 -0.0 1.0 0.0 127 48 192 comment 41 left-most front t1-5.0 0.0 0.0 -0.8944271 -0.44721356 0.0 191 56 224 comment 42 left side t0-7.0 4.0 2.0 -0.8944271 -0.44721356 0.0 191 56 224 comment 43 left side t0-7.0 4.0 0.0 -0.8944271 -0.44721356 0.0 191 56 224 comment 44 left side t0-7.0 4.0 2.0 -0.8944271 -0.44721356 0.0 191 56 224 comment 45 left side t1-5.0 0.0 0.0 -0.8944271 -0.44721356 0.0 191 56 224 comment 46 left side t1-5.0 0.0 2.0 -0.8944271 -0.44721356 0.0 191 56 224 comment 47 left side t1-5.0 0.0 0.0 0.0 0.0 -1.0 255 64 0 comment 48 bottom center t0-7.0 4.0 0.0 0.0 0.0 -1.0 255 64 0 comment 49 bottom center t07.0 4.0 0.0 0.0 0.0 -1.0 255 64 0 comment 50 bottom center t07.0 4.0 0.0 0.0 0.0 -0.99999994 255 64 0 comment 51 bottom center t15.0 0.0 0.0 0.0 0.0 -0.99999994 255 64 0 comment 52 bottom center t1-5.0 0.0 0.0 0.0 0.0 -0.99999994 255 64 0 comment 53 bottom center t14.5 4.0 0.0 0.0 0.0 -1.0 63 72 32 comment 54 bottom front stage t0-2.5 6.0 0.0 0.0 0.0 -1.0 63 72 32 comment 55 bottom front stage t02.5 6.0 0.0 0.0 0.0 -1.0 63 72 32 comment 56 bottom front stage t0-2.5 6.0 0.0 0.0 0.0 -1.0 63 72 32 comment 57 bottom front stage t14.5 4.0 0.0 0.0 0.0 -1.0 63 72 32 comment 58 bottom front stage t1-4.5 4.0 0.0 0.0 0.0 -1.0 63 72 32 comment 59 bottom front stage t1-5.0 0.0 2.0 0.0 0.0 0.99999994 127 80 64 comment 60 top center t05.0 0.0 2.0 0.0 0.0 0.99999994 127 80 64 comment 61 top center t07.0 4.0 2.0 0.0 0.0 0.99999994 127 80 64 comment 62 top center t07.0 4.0 2.0 0.0 0.0 1.0 127 80 64 comment 63 top center t1-7.0 4.0 2.0 0.0 0.0 1.0 127 80 64 comment 64 top center t1-5.0 0.0 2.0 0.0 0.0 1.0 127 80 64 comment 65 top center t14.5 4.0 2.0 0.0 0.0 1.0 191 88 96 comment 66 top front stage t0-2.5 6.0 2.0 0.0 0.0 1.0 191 88 96 comment 67 top front stage t0-4.5 4.0 2.0 0.0 0.0 1.0 191 88 96 comment 68 top front stage t0-2.5 6.0 2.0 0.0 0.0 1.0 191 88 96 comment 69 top front stage t14.5 4.0 2.0 0.0 0.0 1.0 191 88 96 comment 70 top front stage t12.5 6.0 2.0 0.0 0.0 1.0 191 88 96 comment 71 top front stage t13 0 1 23 3 4 53 6 7 83 9 10 113 12 13 143 15 16 173 18 19 203 21 22 233 24 25 263 27 28 293 30 31 323 33 34 353 36 37 383 39 40 413 42 43 443 45 46 473 48 49 503 51 52 533 54 55 563 57 58 593 60 61 623 63 64 653 66 67 683 69 70 710--------- The line above is the last line of the file.
RJStover.