Welcome to WSL!

Make yourself at home, but before posting, please may I ask you to read the following topics.


Posting 101
Server space, screenshots, and you

Thank you!

PS. please pretty please:


Image

[BETA] stMap Macro

Where the future is being made, today.

Welcome to the WSL development corner!

In this forum, please post your development projects. You get kudos and feedback here.
Topics ideally have preset prefixes, and this is what they (might) mean:

  • [DEV] - very much work in progress, don't build a business on this, could go anywhere
  • [BETA] - should kinda do what it's supposed to do, please test, give feedback
  • [RC] - this may end up in Reactor soon, polishing up, now's the time for last minute thoughts
  • [ABD] - died a premature death, sadness, will not see the light of day ever (unless someone picks up the scraps)

Once a development project has been released (hurray), topics can be marked as - you guessed it - [RELEASED] :cheer:

Development topics only, please. For generic questions, how-to's, questions and inquiries about existing tools etc, please go to the appropriate other forums.
User avatar
Millolab
Fusionista
Posts: 568
Joined: Wed Oct 24, 2018 6:26 am
Answers: 3
Been thanked: 81 times
Contact:

Re: [BETA] stMap Macro

#16

Post by Millolab » Sun May 03, 2020 4:16 am

@SecondMan I first made this macro on f16.1 and it was not as slow. On f16.2 got damn slow.
I thought about a macro that accommodates different map types but that seems a lot of work.
Also. this macro would be no use if the Texture node wasn't neglecting the DoD!!

:banghead: :banghead:

User avatar
SecondMan
Site Admin
Posts: 4501
Joined: Thu Jul 31, 2014 5:31 pm
Answers: 28
Location: Vancouver, Canada
Been thanked: 121 times
Contact:

Re: [BETA] stMap Macro

#17

Post by SecondMan » Sun May 03, 2020 10:59 am

Millolab wrote:
Sun May 03, 2020 4:16 am
On f16.2 got damn slow.
Worth sending to BMD if that is reproducible.
Millolab wrote:
Sun May 03, 2020 4:16 am
but that seems a lot of work
Oh I seeeee :mrgreen:

User avatar
Millolab
Fusionista
Posts: 568
Joined: Wed Oct 24, 2018 6:26 am
Answers: 3
Been thanked: 81 times
Contact:

Re: [BETA] stMap Macro

#18

Post by Millolab » Mon May 04, 2020 5:45 am

SecondMan wrote:
Sun May 03, 2020 10:59 am
Oh I seeeee
:wsl: :wsl: :wsl:

User avatar
white_wizard
Fusioneer
Posts: 54
Joined: Wed Sep 18, 2019 3:53 pm

Re: [BETA] stMap Macro

#19

Post by white_wizard » Sun Jul 26, 2020 10:57 am

I've tried every method and macro for using my stmaps (generated in 3dequalizer) within Fusion.

So far my best solution was using a texture node for undistorting plates (required step before planar tracking in Fusion). and modifying the UV_Positioner macro to crop the input image (which are overscanned cg renders) to the plate size (clipping mode set to none). 3de exports stmaps with a dataWindow and displayWindow. The dataWindow is the displayWindow (plate resolution) plus an overscan margin.

While the dataWindow doesn't appear in Fusion even when I display DoD, it seems to still apply the distortion correctly through the UV_positioner macro as long as the initial crop is set to no clipping. If no crop is applied, then the result appears scaled down due to the UV_positioner remapping the entire overscanned image.

I've tried the UV_displace macro but it doesn't work consistently enough with the plates and stmaps I use.

To simplify things, you could do what I've done and set the crop height/width equal to the resolution of the input stmap. Then provide a check box if the provided stmap contains a datawindow/displaywindow discrepancy. Even better if there's a way for a Fusion script to be able to detect that.

User avatar
Millolab
Fusionista
Posts: 568
Joined: Wed Oct 24, 2018 6:26 am
Answers: 3
Been thanked: 81 times
Contact:

Re: [BETA] stMap Macro

#20

Post by Millolab » Mon Jul 27, 2020 10:45 am

white_wizard wrote:
Sun Jul 26, 2020 10:57 am
I've tried every method and macro for using my stmaps (generated in 3dequalizer) within Fusion.

So far my best solution was using a texture node for undistorting plates (required step before planar tracking in Fusion). and modifying the UV_Positioner macro to crop the input image (which are overscanned cg renders) to the plate size (clipping mode set to none). 3de exports stmaps with a dataWindow and displayWindow. The dataWindow is the displayWindow (plate resolution) plus an overscan margin.

While the dataWindow doesn't appear in Fusion even when I display DoD, it seems to still apply the distortion correctly through the UV_positioner macro as long as the initial crop is set to no clipping. If no crop is applied, then the result appears scaled down due to the UV_positioner remapping the entire overscanned image.

I've tried the UV_displace macro but it doesn't work consistently enough with the plates and stmaps I use.

To simplify things, you could do what I've done and set the crop height/width equal to the resolution of the input stmap. Then provide a check box if the provided stmap contains a datawindow/displaywindow discrepancy. Even better if there's a way for a Fusion script to be able to detect that.
I've been using this macro in production.
StMaps generated in 3DE.
It works on my end.
ml_stMap.setting
You do not have the required permissions to view the files attached to this post.

User avatar
white_wizard
Fusioneer
Posts: 54
Joined: Wed Sep 18, 2019 3:53 pm

Re: [BETA] stMap Macro

#21

Post by white_wizard » Sun Aug 02, 2020 9:57 am

Finally tested your macro and it seems to work well. Having to provide the input plate (assuming to set the correct input resolution?) is a more full-proof method. When comparing to my own stmap macro I discovered a few instances where mine was interpreting the frame size wrong, resulting in a stretched image.

Is there a reason this isn't on Reactor?

User avatar
Movalex
Sir Requestalot
Posts: 242
Joined: Fri Nov 03, 2017 5:36 am
Answers: 4
Been thanked: 43 times
Contact:

Re: [BETA] stMap Macro

#22

Post by Movalex » Wed Aug 05, 2020 3:24 am

I think this should not be beta any more. Please Reactorize it!