NP Station

add-ons
architecture

(nBurn) #21

Nice!

Thanks, I’ll look into it.

Force of habit. I used CTRL+LMB to place the first point and when it asked for the second choice (rotation plane) for some reason I assumed it would be another point like the 1st and pressed the control button again. It’s a PEBCAK error, but given the workflow I wouldn’t be surprised if a lot of people trying out Roto Move make the same mistake.

I thought it might have been to fix some weird fix like that. I had to do a lot of those myself.

Wow, that’s far more complex than I realized. Hmm… Are you sure Blender (and/or one of the Python/numpy libraries) couldn’t most of that for you? That could massively simplify your rotation code. I know Blender has XYZ and “arbitrary axis” (spherical) rotations built into the “bpy.ops.transform.rotate” macro and also into the Vector, Matrix, and Quaternion classes. The somewhat tricky part with using the classes for rotations is you have to align your coordinates so they are being rotated around the “world center” (0,0,0), but I think there might be a way to do that on the fly.

I ended up dropping most-to-all of my add-on’s custom rotation code and switching to Blender API stuff. Thanks to that I was able trim off something like 50 or more lines of code and get a little performance boost in the process (the benefit of doing calculations with Blender’s compiled C instead of interpreted Python).

lol

No problem :cool: It seemed to still work during the quick test run I did, but you may want to do further testing. I can upload my edited version of “get_eul_z_angle_difffff_in_rotated_system” if you want.

Hmm… If it helps, I was launching “NP 020 Point Scale” from the spacebar menu. I didn’t have this issue when launching Point Scale from the Tools Panel.

Steps:

  • Select mesh obect
  • Launch “NP 020 Roto Move” from spacebar menu and rotate the object
  • Undo the roto-move operation so the object is back to its original state
  • Launch “NP 020 Point Scale” from spacebar menu with same object selected

I will go into more detail. With the current “NP 020 Point Distance” as soon as you select the second vertex, the add-on exits and the on-screen measurements disappear (changing Step from Simple to Continuous wouldn’t fix this). My request is to have the add-on stay running after the second vertex is selected (so on-screen measurements stay visible). Then you could do something like zoom in or out or rotate the 3D View to see the individual measurements from multiple viewpoints. That would be very useful for documenting dimensions.

Thanks for the reply. I’ll let you know if I run into any more bugs and I will keep an eye out for updates.


(urkokul) #22

The good idea and good work. Thanks


(Okavango) #23

@MatsuikoHiroka

thank you for reply and confirmation
so its hard codded and not possible to change ;/
i wish it can be change somehow

No problem, glad if it helps. Don’t forget, although it is hard coded, you still have an option to change it to one of those four keys (selection mouse / ENTER / numpad ENTER / SPACE), so you can resolve your specific problem.

that tool is a must have for me

it reminds of this but with visual guide
https://www.youtube.com/watch?v=gfnX5MYXNfk

Yeah, 1D_inc is a CAD beast :slight_smile: He’s pretty good at animations too, as far as i can see. Good feel for the motion and timing.


(Okavango) #24

@nBurn

I used CTRL+LMB to place the first point and when it asked for the second choice (rotation plane) for some reason I assumed it would be another point like the 1st and pressed the control button again. It’s a PEBCAK error, but given the workflow I wouldn’t be surprised if a lot of people trying out Roto Move make the same mistake.

Good point, i will have to look into that. Some more dramatic graphics change upon that second choice, perhaps. As a matter of fact, i just noticed that in my gif video there is an old instruction interface where it says ‘CTRL for snap’ when choosing the plane… My bad…

Wow, that’s far more complex than I realized. Hmm… Are you sure Blender (and/or one of the Python/numpy libraries) couldn’t most of that for you? That could massively simplify your rotation code.

I know Blender has XYZ and “arbitrary axis” (spherical) rotations built into the “bpy.ops.transform.rotate” macro and also into the Vector, Matrix, and Quaternion classes. The somewhat tricky part with using the classes for rotations is you have to align your coordinates so they are being rotated around the “world center” (0,0,0), but I think there might be a way to do that on the fly.

I ended up dropping most-to-all of my add-on’s custom rotation code and switching to Blender API stuff. Thanks to that I was able trim off something like 50 or more lines of code and get a little performance boost in the process (the benefit of doing calculations with Blender’s compiled C instead of interpreted Python).

The fact is, i need to emulate the exact same value that appears on the header while the rotation is active: http://pasteall.org/pic/show.php?id=113363 The problem with this value is that it can go into both positive and negative directions, can read multiple rotations (eg 758 degrees, -1525 degrees, etc) and measures the value around an arbitrary axis. That is the exact value that is shown on the header while roto-move is working, i just need the way to replicate it and the eulers are the only type that i found that can handle these features. I was hoping that there would be a native API way to, but i couldn’t find it, and the developers say this value is not exposed to python. So - i had to calculate it. If you know how to achieve that without the eulers, i am very open to suggestions.

No problem It seemed to still work during the quick test run I did, but you may want to do further testing. I can upload my edited version of “get_eul_z_angle_difffff_in_rotated_system” if you want.

Of course, if you don’t mind. Just add another ‘f’ :smiley:

Hmm… If it helps, I was launching “NP 020 Point Scale” from the spacebar menu. I didn’t have this issue when launching Point Scale from the Tools Panel.

Steps:

Select mesh obect
Launch "NP 020 Roto Move" from spacebar menu and rotate the object
Undo the roto-move operation so the object is back to its original state
Launch "NP 020 Point Scale" from spacebar menu with same object selected

Still can’t replicate it. Just curious, how many times dou you press undo for the roto_move? It takes three undo’s to completely revert it (one for the object and two for the helper objects). Maybe that could be the problem.

I will go into more detail. With the current “NP 020 Point Distance” as soon as you select the second vertex, the add-on exits and the on-screen measurements disappear (changing Step from Simple to Continuous wouldn’t fix this). My request is to have the add-on stay running after the second vertex is selected (so on-screen measurements stay visible). Then you could do something like zoom in or out or rotate the 3D View to see the individual measurements from multiple viewpoints. That would be very useful for documenting dimensions.

Ah, i think i get it now. I think it can be easily implemented, i’ll see to add it in the next version. Thanks for the suggestion.


(Okavango) #25

No problem, glad if it helps.


(mkbreuer) #26

Hy Okavango,

When i run the NP Point Align and execute it in the 3d view without any snap, this error pops up:


Traceback (most recent call last):
  File "NP_020_point_align.py", line 560, in execute
    value = (tome.vertices[0].co) - (fromme.vertices[0].co + fromob.location)
IndexError: bpy_prop_collection[index]: index 0 out of range, size 0

location: <unknown location>:-1

After then it will not work anymore. I have to restart blender.
Is there a way to avoid the execution without a snap?


(Okavango) #27

@mkbreuer,

thanks for the report, i succeeded to reproduce the bug when hitting RMB before any point is designated. Is this what you meant? If it is, check the new file in the attachment.

@nBurn,

i made a prototype version of the hold result step for point_distance, check if that is what you were talking about, the same attachment.

EDIT: Attachment moved to project page https://developer.blender.org/T50832, bottom of page, the last file in the thread


(mkbreuer) #28

Yes, exact what i meant! It works perfect now.
Amazing! Thank you!


(Okavango) #29

Great! Here’s what i also got with nBurn’s idea, could be useful in some cases:

http://pasteall.org/pic/show.php?id=114004


(nBurn) #30

Ah, that’s what the code is doing. Did you ask about this somewhere else? I’m getting a strange case of deja vu…

lol, no problem. Here’s a link to the quick fix I tried. Remember to update NP_020_point_move.py after adding my “updated version” to utils_geometry.py (I forgot to and wasted a bit of time trying to figure out why I wasn’t seeing any changes).

Side note, but I ran into issues using the “==” operator on floats in early versions of my add-on. Instead of using round I went with a function similar to the math.isclose() feature that was added to Python 3.5. I wasn’t aware Python had that function, so I slapped together my own float comparison function (link removed). Something to consider.

I double checked the Blender source code and it appears you were right. That “Rot:” value looks like it’s being sent to the interface straight from a “ED_area_headerprint” call in the “transform.c” source file without going through Python, so it might not be directly accessible through the API. There may still be a way to get to it going through Blender’s RNA, I think dairin0d did something like this in one of his add ons, but his code seemed rather complex. It might be easier to stick to calculating it manually. I was wrong about the Vector class, they can do both positive and negative angles with the “.angle_signed” method (recent script I made test it out), but they flip from positive to negative (or vice versa) when you go above 180 degrees or below 0 degrees, so I’m not sure they would work as a Euler replacement. If all else fails there’s always the option of digging further into Blender’s source code and just copying whatever method Blender is using internally to calculate the value.

It’s something related to my current Blender install that’s causing the problem (either a change in the preferences or a conflict with another addon I’m running). “NP 020 Point Scale” was still skipping the scale point selection part even without reverting the changes from “NP 020 Roto Move”, so to double check I ran NP Station from a Blender nightly release that isn’t using any of my current Blender preferences and Point Scale ran as intended after running Roto Move. I’ll do some more troubleshooting to see if I can isolate the root cause.

Very nice! Just tried it out, this is exactly what I wanted, thanks.


(Okavango) #31

Ah, that’s what the code is doing. Did you ask about this somewhere else? I’m getting a strange case of deja vu…

Yes i did, in several places, including the #blendercoders on IRC. This thing has been bugging me for some time now.

lol, no problem. Here’s a link to the quick fix I tried. Remember to update “NP 020 Roto Move” to use my “updated version” (I forgot to and wasted a bit of time trying to figure out why I wasn’t seeing any changes).

Side note, but I ran into issues using the “==” operator on floats in early versions of my add-on. It might be worth looking into something like Python’s newish “math.isclose()” feature added in 3.5. I wasn’t aware Python had that feature, so I slapped together this float comparison function as a workaround. You might be able to swap out your “round” calls with this as well.

Ok, thanks, i will update the roto_move with that one. I will check the rounding issue also and i might just use your function, seems useful.

I double checked the Blender source code and it appears you were right. That “Rot:” value looks like it’s being sent to the interface straight from a “ED_area_headerprint” call in the “transform.c” source file without going through Python, so it might not be directly accessible through the API. There may still be a way to get to it going through Blender’s RNA, I think dairin0d did something like this in one of his add ons, but his code seemed rather complex. It might be easier to stick to calculating it manually. I was wrong about the Vector class, they can do both positive and negative angles with the “.angle_signed” method (recent script I made test it out), but they flip from positive to negative (or vice versa) when you go above 180 degrees or below 0 degrees, so I’m not sure they would work as a Euler replacement. If all else fails there’s always the option of digging further into Blender’s source code and just copying whatever method Blender is using internally to calculate the value.

You can read C? That is great, i haven’t tried it yet. Good thing if you found it, at least we know where to look now. I was talking to Campbell (ideasman42) the other day, whether that value can be accessed with Python and he said it is not possible. However, i did experiment with something he mentioned - operator properties. There is a set of properties that can be accessed when Blender’s transform operator is active, like axis, constraints etc. But, that particular value is not disclosed while in modal operation, i tried to display it. So, if you have any idea how to fetch it from the source that would be awesome. One option is, we intercept it somehow after the calculation, the other is we emulate the exact way it does it’s calculations. I actually got the digits to change with the movement, but the formula is flipping up and down when on orthogonal and negative surfaces.

Yeah, vectors are helpless in this multi-rotation tracking.

Optionally, Campbell Barton said he could probably output that value as a string but he is not convinced it should be done because it seems flaky (unprofessional), and he is probably right. Perhaps we should try to dig further into the code and if we don’t manage, to try and talk to him.

It’s something related to my current Blender install that’s causing the problem (either a change in the preferences or a conflict with another addon I’m running). “NP 020 Point Scale” was still skipping the scale point selection part even without reverting the changes from “NP 020 Roto Move”, so to double check I ran NP Station from a Blender nightly release that isn’t using any of my current Blender preferences and Point Scale ran as intended after running Roto Move. I’ll do some more troubleshooting to see if I can isolate the root cause.

Ok. Good that you narrowed down the problem. I have a feeling the trick is in one of your userpref or viewport settings, it would be good if you could pinpoint it, so i can try and prevent it from occurring again if someone else has the same settings.

Very nice! Just tried it out, this is exactly what I wanted, thanks.

No problem. Nice suggestion btw, it gave me some new ideas.


(nBurn) #32

Hmm, maybe that’s where I saw it.

I can read standard C and some C++, but I’m still fairly lost when looking at Blender’s source code. It’a a huge code base and uses a lot of 3rd party libs.

I think it depends on whether it hits Blender’s RNA or not, but I’m not 100 percent sure about that (don’t know much about Blender’s RNA setup). I’m also not sure where the actual rotation value is calculated, just where end result is formatted before being sent to the header bar.

Nice, that would save a lot of hassle, but I understand see why he might not want to do it. If it’s a no go, just getting the specific place in the source code where the rotation is calculated should be enough.

Now if he’s up to requests… :cool: My vote’s for something like a “closest_vert_in_2D_scene_space” and “closest_object_in_2D_scene_space”. Methods that you could send a 2D vector to (like the mouse location) and then get a “3D” result back. Sort of like the “closest_point_on_mesh” method. With those two you wouldn’t have to use macros anymore.

I don’t think I narrowed it down anymore. I did some more testing and “NP 020 Point Scale” still seems to be randomly skipping the point selection part. Often just running Point Scale twice in a row will make it skip the selection part on the second run and this was with a vanilla Blender install (with the default UI preferences and addons). If it helps, these were a few of the addons I tried with it that seemed to make it skip on the first run:

  • Mesh: 3D Print Toolbox
  • Mesh: tinyCAD Mesh tools
  • Object: Carver MT

The Blender version I tested it with was “blender-2.78.0-git.9de9f25-windows64” (one of the nightly builds).


(Okavango) #33

I think it depends on whether it hits Blender’s RNA or not, but I’m not 100 percent sure about that (don’t know much about Blender’s RNA setup). I’m also not sure where the actual rotation value is calculated, just where end result is formatted before being sent to the header bar.

Nice, that would save a lot of hassle, but I understand see why he might not want to do it. If it’s a no go, just getting the specific place in the source code where the rotation is calculated should be enough.

It’s ok, we will find it. I think Mano Wii could help out also, he is pretty proficient with C, he mentioned he could probably locate it.

Now if he’s up to requests… My vote’s for something like a “closest_vert_in_2D_scene_space” and “closest_object_in_2D_scene_space”. Methods that you could send a 2D vector to (like the mouse location) and then get a “3D” result back. Sort of like the “closest_point_on_mesh” method. With those two you wouldn’t have to use macros anymore.

Yes, exactly. Actually, that particular topic has already been defined and tackled by Mano-Wii. If there’s one person who could sort out Blender’s snap it is him. I am not sure if he will address these exact features, but he will upgrade snapping definitely, and he did mention exposing snapping to python…

I don’t think I narrowed it down anymore. I did some more testing and “NP 020 Point Scale” still seems to be randomly skipping the point selection part. Often just running Point Scale twice in a row will make it skip the selection part on the second run and this was with a vanilla Blender install (with the default UI preferences and addons). If it helps, these were a few of the addons I tried with it that seemed to make it skip on the first run:

Mesh: 3D Print Toolbox
Mesh: tinyCAD Mesh tools
Object: Carver MT

The Blender version I tested it with was “blender-2.78.0-git.9de9f25-windows64” (one of the nightly builds).

Tried to reproduce it with 2.78b, with use after tinyCAD 1.2.9., Carver MT 1.1.6, multiple point_scale activations, activation after roto_move, still nothing.

Maybe some giff with keys screencast showing it while it happens?


(bekic.bojan) #34

Thanks for a great tool! Very very useful and user friendly (and good looking)!


(Okavango) #35

You’re welcome bekic.bojan, thanks for the compliments. There are many more ideas, but not much time to make them happen.

Also, there is a chance the addon will be included in 2.79RC addons_contrib collection.


(nBurn) #36

Sorry for late response, forgot or didn’t realize you had replied to my last post.

Yeah, I’ve talked with him about this before. He’s been working on it for some time, but improving the snapping system in a way that doesn’t break core features is quite difficult from the sounds of it.

I’ve attached a GIF of the problem below. You can see it starts fine when launched from the tool bar, but it seems like when I launch from the spacebar menu, something is causing the addon to start with a “Left Mouse Click” already detected in the event system.

https://media.giphy.com/media/l0Iy3645fzzpv7yne/giphy.gif


(Okavango) #37

Ah, ok. I think i have a hint what’s going on. Try this version:
https://wiki.blender.org/uploads/6/61/NP_020_2017_04_13_repaired_ps.zip

P.s. What OS are you on?


(nBurn) #38

Wow, fast update. I tried it out and this version fixes the issue.

Windows 10 (x64).

EDIT: One other question. Wouldn’t “point_copy”, “point_instance”, and “point_array” be a better fit in the “Create” group (or maybe a “Duplicate” group) or is there a special reason they are under “Modify” ?


(Okavango) #39

Well, it is an open question. You actually could be right. The problem is, ‘copy’ command in standard CAD apps is usually in ‘modify’ toolbars, which makes sense with it being a very close relative of the ‘move’ command. The same goes for the point_instance and point_array. However, they do create new geometry.

The real question is: is the copy / instance / array closer to ‘move’ (with deleting the source object) or to ‘box’, ‘rectangle’ and others. For now, i went with the modify tools. Perhaps your idea of a new category is worth considering though.


(nBurn) #40

Thanks for the explanation. I was mostly just curious as to what the reasoning was. I had not considered keeping similarity with common CAD setups, but it makes sense from that perspective. Guessing AutoCAD background?

I had a few code related questions if you don’t mind me pestering you some more later. I’ve been researching NP Station’s point placement and snapping code as a possible replacement for my addons current point finder, but there was a few parts I couldn’t figure out. I have a little more investigating to do first though.