Bad Mapper cropping issue.
Content does not scale when changing the crop values - only debug cells are.
For some reason when disconnecting the screen space values from the homography camera it’s working again. But won’t update when connected back am I missing something?!
VL.BadMapper.0.0.20-alpha. Anyone to confirm this?
BadMapperCrop.vl (28.4 KB)
Hey desax,
happy to hear of you!
It’s been a while that I was working on that node set. But after playing a bit with the help patches and your example patch I think the behavior is by design.
I completely understand that by design not always feels right or fits a certain workflow or mental model, but from a certain angle it is feels correct:
If you start with meassuring your screens and know where they are you typically start thinking of your “canvas”: the area are that spans all projections.
If you now make your projectors overlap, you zoom in and out until happy and you’d enter the max overlap in %. But changing the value will not scale the content. Why?
If you think about it: by feeding one big texture for the whole canvas you already defined where which pixels shall land. The projectors are only there to “reveal” that content.
Another more extreme example that shows why it is implemented the way it is.
Imagine you have a mapping where projectors need to hang in strange positions and some can reveal more, others can reveal less content.
I once needed this for a project and wanted to define the content and afterwards move where one projector stops revealing content and the other takes over. Including different softedge.
I think this is the mental model that lead to overlap adjustments are something local, that shall not scale content.
But to be fair. Had to open old versions of vvvv and badmapper in order to find out that this is not a bug but desired behavior. So I give you that this is a bit confusing.
Hope it helps.
Hi Sebastian,
thank you for explaining this, I get it, but we are talking about two different nodes and behaviors here:
Grid.Mapping and Grid.Mapping (Single Mesh)
The first one is compensating content size per output depending on the Overlap values and screen count distribution as the Multiscreen implementation in vvvv_beta.
The second one on another hand, is estimating coverage using a 3d model, is resolution/size dependent and allows you to set Overlap Range values making it possible to adjust the visible area of the projected content individually- therefore making your point completely valid.
You can check what I’m talking about by comparing ‘Example Grid Mapping with SoftEdge And Masking’ and ‘Example Grid Mapping on Cylinder’. Both examples are using a similar screen distribution (3x1) but the overlap is behaving differently.
Regarding the first implementation, the issue I’m talking about seems to be only occurring when the screen count is =2, either horizontally and vertically. Otherwise everything is working as intended.
Kind regards.
Ok I checked and it looks to me that ‘Example Grid Mapping with SoftEdge And Masking’ is behaving wrong with 3, but with 2 I feel in control again - content isn’t swimming.
Looks like a bug, but not for your scenario.
I found a workflow that works with this nodeset for 2 and 3 projectors:
no swimming
