User Profile

The fastest way would be to compare two "boxes" in 3D space. You simply check if any one of the box A's points are inside box B. Since SceneKit's "getBoundingBoxMin:Max:" is still broken, you will have to make up with the locations of the points yourself. Simply create some variables for your points, and extend their locations based on the node's position. If your game is not moving around vertically so much, you may not need to compare all the points of the two boxes. Instead just compare the 2D locations as if the world was flattened. (Or even go further to simply compare the node's singular point position against a 2D box) That would be the most efficient way. Both SceneKit's physics engine and doing a distance calculation, (as gchiste proposed), would be heavier than comparing box points. - And it is not much effort to compare points like that.

Dear Apple Graphics Engineer, I can clearly see it. The craftsmen I work with can tell. You essentially say you can not see it, or that you think it is insignificant, or perhaps you just haven't tried it yet to know how bad the artifacts are in the context of a drawing tool. Think about that situation. This should normally go without explanation, but an artist is someone who's skillset is developed by refining the perceptual acuity of their senses. They are a person who exercises physical organs beyond a normal person to the extent that we can measure changes in the physical matter across even 2-3 months with MRI. We are talking about a group of people who are physically more developed to see better than the average person. In order to be more acute in their work, they must actively and intentionally look, observe, and pay attention to subtle details that a normal person's brain would skip over. They see things that others are blind to. Relatively, the perceptually more blind people would say, "It looks good to me, I can not tell the difference", while the people who developed more refined and acute perceptual and observation abilities, can not only distinguish that level, but even further levels depending on their level of physical development. As an engineer, you likely have experienced this phenomena to some degree yourself in another area of practice, where your acuity increased in response to how you trained your body. It is also well known, that without continued exercise, the organs will not maintain their abilities, and the brain will reorient itself toward the demand of more present activities. Because of this, it is only the people who do the skills regularly and exercise the body in the proper form, who retain the deeper levels of perceptual acuity. When a person comes to us and says, "I am the target audience in question, and I can see and am observant of things that you are not, and they do matter", then we have to accept that our own abilities are inadequate to clearly see and understand. Even if you were informed of the reality of it, you wouldn't physically be able to see it yourself, and thus be inclined to believe that it looks okay, when it really looks terrible and sticks out like a sore thumb. To try to develop truly sincere drawing tools for a select few craftsmen in another country, I exercised the body and senses to become extremely critically aware of things like this beyond the average person. I then rigorously analyzed why the iPad hardware and software was failing for the sincere use case of real craftsmen. I came to be very familiar with a sea of specific core problems at Apple with the people and resulting products. This observational and perceptual issue is one of those core problems. Even if you feel and say to me, "I personally do genuinely care", if your present perceptual ability is not at a high enough level, you won't be able to make proper judgements of quality, and then people like me will think "this person has shallow perception and/or is disingenuous about quality". - They just wont vocalize it clearly because it's likely to be taken offensively instead of just an assessment of the reason the problem exists. It's the same reason Apple staff thinks the lag problems are not significant. But, because neglected root problems like this have led the Apple engineers' and managements' output to get much worse over the years - not just on functional use issues, but also oversights of severe global health issues, I am becoming a more vocal detractor.

I'm practically retired and don't really work for money, so I can't help you with that. But, what I would suggest, since you've been working on it long enough... Is to reassess your Application Definition Statement. Take a hard look at what solution and differentiator you are actually providing. Why do you believe your prototype depicts something that a more experienced developer would need to see? What is the real purpose of making such a prototype? ... As for the health problems... It comes from: A) The touch pad B) The induction coil C) The magnet D) Bluetooth modulation (distinct from older modulation formats) E) The iPad's touchscreen itself F) General lowering standards of material choices, like GF2 The last few existed along with the Apple Pencil 1, and they were measurably bad, but the additions and design of the Apple Pencil 2 are on another league of damage. The thing here, is if I just list these things, no one will actually understand anything. In fact, they might assume that I don't know what I'm talking about, and am just one of those tin foil hat people who are afraid of microwave radiation. (As opposed to being informed with actual measurements and having constructed custom antenna and hardware that replicate the phenomena) We can only describe things in relation to things you already understand. If I talk about specific measurements I personally took, and describe how certain very specific kinds of electromagnetic field patterns interact with different specific materials in specific layouts, and how those interact with the body - then we'd have to go very deep in describing the internal hardware and measurements. The problem with having such a conversation in public, is similar to how we have trouble talking about the fundamentals of programming in Metal. Just like there are very complex 'decision-consequence' chains in writing your Metal program, there are similar phenomena of 'decision-consequence' chains in the hardware for health safety. Most people don't even understand the surface level of basic signal noise phenomena - where we can even pollute the battery on purpose to demonstrate functional use errors in the form of drawing stroke gaps. (Also notice how the Apple graphics engineer's responses are not always informed enough.) Just like how Apple releases obvious bugs in software that show they don't do proper testing, it's the same with the hardware. They are not measuring like I was. Otherwise, fundamental mistakes in material science and antenna design would have never have gotten this far out of hand. The problems of the electronics are a result of the same people problems that are present in the software. And it's not like we really needed those features in the Apple Pencil 2. Especially the touch pad. That's quite a big health problem for something I personally didn't even want to use. Using the induction coil to charge, means that the signal is always more polluted that what we had in the Apple Pencil 1. And like I pointed out, the signal noise will trigger stroke gaps - because the touch screen is an analog antenna array. It's just outright ignorance for engineers to do these things. And to not understand how the materials, purity, layout, and fabrication choices influence the interactions, is like saying the engineer is missing fundamental understanding required to be adequate for their role. Why are we repeating age old mistakes like how the shell is reverberating the signal of the processor at an audible level, and out through the cable? And I can almost predict that even though they were told years ago, the material choices and construction of the next iPad will be even worse. You would think a rational company that says "we care" would listen to things they could easily avoid ahead of time, and that's what makes me so upset about it.

Dear Apple Graphics Engineer, That isn't a valid solution in this context. Because if the artist has the observational acuity to see the artifacts in the first place, then merely moving to sRGB won't satisfy the problem. You can see clearly what I mean if you actually try it.

The banding artifacts come from the bit size per component being too small. So the solution is to increase the bit size, but it has a daisy chain of consequences - you will see situations like that a lot as you go further. Things unravel into complex choice-consequence chains, when you really try to make the real thing. Let's say you chose MTLPixelFormatBGRA10_XR, it would have less banding, but now it is slower and you are in a different colorspace entirely that goes beyond the bounds of 0.0 to 1.0. You then have to rewrite the rest of the code to work in that format - and if you want to save to a file, you also will face a battle converting out of 10 bits. (But you don't convert out of 10 bits, you would have to accept the consequence of needing to render a different format for saving) If you choose a higher bit per component like MTLPixelFormatRGBA16Float, you will get even less artifacts as you go up, but again, slower, and it's in a different order.

While UIKit should really never be used - rendering to offscreen textures has other performance consequences and dozens of adjacent things you have to implement for a typical drawing tool. Sometimes it is necessary, but not always, and the difference is large. If it's slowing down already, you should first address that as I did - and you may not want to hear this, but I would bet on it that your app is also suffering from cpu performance problems in how you manage the stroke data, the memory, and of course, that you are using Swift (which by now, if it isn't clear, is in fact ironically slow and not appropriate for a performant drawing tool) From reading what you wrote in the other threads, I could predict with high certainty there are dozens of other common fundamental things causing the performance problems you are experiencing, well before you even confront the ones Apple is responsible for. I've built many drawing tools that optimize for different use case workflows, and each one required different arrangements based on their specifics to truly get a stable 120 fps (That is, before apple messed up the Display Link path). You may not want to hear this, but you are only around 10% there. But, really, there is a bigger problem. If we are to try to be moral people who care about each other, then we have to pause before talking about all that code, and talk about the serious health damage introduced with the Apple Pencil 2nd generation. If we are making tech demos or toys for ourselves and we accept the health damage for our own body that is one thing, but when we talk about releasing apps that have a tendency to lure people to use the Pencil more, then these moral health concerns have to be assessed. Are we not morally responsible for the activities we encourage through the apps we make? If we become aware as third party developers that the Apple Pencil 2nd gen is a serious health problem, and that the users are not aware of it - don't we then have an obligation to be responsible for that? The science of how bad it really is, is over the head of the average person, and it's not something we can clearly and fully warn them about. Apple has continued to ignore the reports, and we can assume they have chosen a position of disingenuous morality - because of this, as developers it really does come down to our personal moral character. You, me, the other developers releasing on the store, our actions and how we choose to respond to the immoral circumstances will determine the extent of the negative impact until Apple listens. So, as much as you may feel attached to your work, and are still struggling with the fundamentals, there are some serious moral concerns with releasing apps for the Apple Pencil 2nd gen today.

That is because blend modes of that kind can only be done manually in your fragment or kernel, not in the pipeline descriptor options. You have to write the math for it yourself and structure the render passes appropriately to perform the compositing. Also fyi, you are going to get banding with that pixel format.

I see, I would also recommend writing a test that does not use a CVPixelBuffer at all. This is because it is important to identify if the culprit is reading from the texture or writing to the buffer. You can do this easily with C inside the Objective-C version. Simply call malloc with the size of your buffer, and pass that pointer to getBytes instead of the CVPixelBuffer. If you find that there is no slow down, you will know for certain that the issue is with CVPixelBuffer's delay and not getBytes. Then you can inform Apple about this in the report. Send me a copy and I will confirm that the test code was written correctly.

Have you confirmed that the assembly code, OS, etc are all identical? (And even before this, did you verify with the gpu debugger that everything is identical? Such as the pixel format and size? Did you verify it against a non-Swift implementation?)

It's more a consequence of the problems of scale: As you increase the scale and number of parts, communication slows down. The fast memory on the chip used for tile memory is smaller. TBDR is about taking advantage of faster memory access with smaller amounts of data that can fit in smaller amounts of physical memory. As far as I am aware, for desktop gpus, there was only one line of Nvidia cards that had something similar. If you run a compute kernel on the M1, you would expect it to be more efficient in memory access in this regard compared to the other gpus. However, in situations that go beyond the M1's storage and processing ability, of course, you would see a point where the overall results would seem like it is underpowered. This is how you know what strategies and use cases are more appropriate for the M1 vs an eGPU. An eGPU is slow in communication no matter how powerful a card you put in there, so it really isn't appropriate for smooth interactive rendering views. It's more appropriate to use eGPUs for non-realtime offscreen rendering. The many other pipeline benefits of TBDR will come into play if your use case is something that really matches what it is best at - but that may often not be the case, and you may still need multiple render passes.