- #Inklet not drawing mac osx
- #Inklet not drawing software
- #Inklet not drawing code
- #Inklet not drawing mac
Perhaps a mouse moved message could be synthesized without actually moving the mouse position? Or would an "unknown event" be acceptable? The second event would mostly be synthesized just to clear the tablet event data, but I couldn't find a similar good example in the source. This is where my knowledge of Blender's architecture mostly ends. First the mouse up with tablet information, and then the tablet proximity event to clear all tablet information. It seems like the right behavior is for there to be two separate events. Also, I found that later events (like window deactivation) were showing tablet events, which would clearly not be the right thing. This was just a test those events are important for tablets with proximity sensors. The mouse up messages have tablet information so pressure get released as appropriate. I can confirm that if I comment out tabletPoint and tabletProximity in WindowCocoaView, the problem goes away. Received a tablet proximity event in WindowViewCocoaĪnd finally, the event is processed internally:
#Inklet not drawing code
However, before that event is processed by Blender's internal event system, the code also processes a tablet proximity event, so the log continues with: In my sidecar test case, when the mouse up event arrives, it is marked with a subtype of NSEventTypeTabletPoint, and the code calls GHOST_SystemCocoa::handleTabletEvent(void *eventPtr, short eventType): The short version is that the mouse up event is getting clobbered by a tablet proximity event. I instrumented the macOS side of the code to verify when the various tablet routines were being called during a basic test using Sidecar and an iPad on Catalina. I've got a partial answer for what's going on - will try to pick this up again tomorrow night, but thought I'd pass on some notes. WmEvent type:260 / WINDOW_DEACTIVATE, val:2 / RELEASE, WmEvent type:272 / TIMER, val:0 / NOTHING, WmEvent type:1 / LEFTMOUSE, val:2 / RELEASE, Shift:0, ctrl:0, alt:0, oskey:0, keymodifier:0, WmEvent type:1 / LEFTMOUSE, val:1 / PRESS,
#Inklet not drawing mac
Is there something you can do to help us Mac people to have a working workflow with our hardware?
Which makes us believe there is a possible conflict with how Blender is sampling input/stroke events in general" But, we were able to get a similar result with just using a trackpad as well, "With the latest, we were able to get pressure sensitivity and reproduce the high pressure end of stroke. I've been in touch with Astropad team and the say:
#Inklet not drawing software
Unfortunately both apps (working fine in other software like photoshop or krita) are experiencing the same issue with blender and are easy to reproduce trying to draw with Grease Pencil: whatever you do the final point of the strokes records 100% pressure on release, drawing a bubble at the end. The same feature is brought to iPad Pros with Astropad turning your iPad in a Cintiq for your Mac. One of the easiest app to use is called inklet and lets you use the trackpad as a graphic tablet. This also means that there are applications out there that are enabling this feature for any osx software without having to code it. This means that you can enable pressure recording in your apps using apple' integrated input/stroke events. As you may know new macBook trackpads are pressure sensitive.
We were recently testing a setup that replaces the Cintiq with iPad Pros.
#Inklet not drawing mac osx
Operating system: Mac OSX 10.14.3 (18D109)īlender registers wrong pressure values on stroke realease when input is given by OSX stroke events from iPad Pro ( Astropad) or Force Touch Trackpad ( inklet)Įxact steps for others to reproduce the error
0 kommentar(er)
