buddard wrote: ↑06 Mar 2020
Sorry, but there are so many misconceptions here that I can't help answering...
I have absolutely 0 inside information about what Reason Studios are up to, but I have been involved in the development of 20+ released REs by now, so I'd like to believe that I have a reasonable grasp on how the RE SDK works.
As per the information recently revealed by Mattias, they are adapting their graphics engine to make use of GPU acceleration.
What are GPUs good at? Drawing lots and lots of textured polygons, i e to quickly draw rasterized graphics, such as panel backgrounds and widget film strips. Among other things, GPUs have on-board texture memory for this very purpose.
So I highly doubt that they're implementing vector graphics, nor do they need to. They set high requirements on graphics resolution in the RE specification from the beginning, and now they can hopefully reap the rewards from making that decision 8+ years ago.
Extensions actually contain 4K ready assets right now.
The resolution of the GUI assets is actually higher than that. For REs using the 2D graphics pipeline, the resolution is 5 times higher than that of the current Reason rack. The older 3D pipeline is a little different since the geometry could be rendered at way, way higher resolutions before you would start to see vertices in "round" objects, but I'd say the overall limit is about the same due to the size limit on textures. Knobs would stay sharp, but the panel textures would start to get blurry.
You've corrected a number of misconceptions, but what you should point out is the resolution of the art assets is a misleading usage. A 754px crop of a full-size image looks like it's a zoom is so going to look "crisp" and showy at non-4K resolutions,
and big for those viewing at 4K, but it's unlikely the device will be that big in 4K in typical usage. Resolution: it's all relative!
In theory, the SDK is set up enough to handle an 8K rack, because of the fact that the SDK devices are produced for 3850 or 4096, and these mythical HiDPI devices
are unlikely to be full width at 4K.
Now, that the 3D pipeline could support high vertice rendering is somewhat untrue, given one wouldn't normally apply huge LODs even for a circle, you'd only add enough for it to look enough like a circle at 4096px, anything more was a) wasteful, and b) likely to get one's device rejected for excessive LODs
, but regardless, what is true is the render size is limited for the exact reason you note: the artwork doesn't go higher than is required for 4K (or 8K
assuming a maximum device width of ~50% of the screen at an 8K resolution, i.e a device width of 3840px). Thinking about 4K specifically however, given that's the size most of us are looking to right now, 4K is 3840px, so the maximum render for a 4K monitor realistically will have to be a fair bit smaller than that, or it'll be wider than the screen, given one needs a margin for things like scroll bars, or window frames.
So while it's easy to understand people "wow"ing at the high res pic you showed this could be rather misleading without explaining.
With a "4K rack", it's not that devices are zoomed in or especially "bigger". The rack should
effectively look as sharp and big at 4K as it does now at the old [W]SVGA/[W]SXGA-compatible format Reason's rack still uses
at their respective resolutions and dot pitches, e.g. you'd have stacks of many devices with two or three columns visible, right up to 8K! We'd return to something like the same relative size, give or take a few %, at the increased resolution and/or small dot pitch (important even at 1080 resolutions on 13/15" laptops).
So what peeps are probably looking at is where the rack device widths will merely double to say, 1650px width per device (a little more than twice the size it is now), which would be an improvement that may be enough at 4K. Now, individual items could potentially be zoomable in a pop-out format like VSTs instead, but those would still be limited to a max width ~3800px. Or a full-rack zoom from "classic" 754 to 3840 "full device" width. Any thought of zooming more just to get a blurry image would be as dumb as a bag of spanners, as the provided artwork doesn't support it.
But remember you have the issue of texture memory for every device in the full rack size, and whether it can be dynamically loaded as each device appears on screen, or all has to be loaded upfront to allow fast scrolling and zooming through the rack without display glitches. People here talk about GPU acceleration and it's easy to fall in a trap with high expectations. In particular those of you who've made these devices on HEDTs, or who play a lot of games and upgrade to the latest gear regularly, it's natural to think of he's talking about latest 2080ti or something! Nope. I mean, I've only got a 1070 for starters!
But seriously, it's potentially all got to render on that Intel-integrated PoS with 2GB texture memory with RAM share on a mid-range FHD 4GB laptop from 2014. It's got to be lowest common denominator stuff. There may have to be tempered tiers of performance expectations and "sorry, just ain't gonna work on your Walmart laptop" type cutoff, but there's still got to be a minimum acceptable state, and that's non-AMD/Nvidia laptop graphics.
So the SDK gui was, by design or accident, set up for an 8K resolution provided the maximum render size is the equivalent of a two rack-column device width at most. But hell, really it's just Samsung trying to push 8K (check out this video for why 8K is simply not needed for domestic purposes: a 4K OLED is way sharper than a Sammy 8K QLED in this sort-of blind test/demonstration, the reasons why are fascinating, so do watch it through,
The 3D pipeline was likely developed to allow the possibility to rasterize at any size up to 4K. It's doubtful there was any serious intent beyond a whiteboard brainstorm for a vector-based rack, after all, while it looked really cool in RED at its native scale, it looks utterly shocking once you zoom out and the LOD reduces and the bitmap blurs, and you can't zoom in from the native scale as the textures then degrade and pixelate/blur.
The sensible approach is re-rasterizing both panels and filmstrips to smaller sizes pretty much
on the fly from original full-size art (this is likely what e.g. Arturia's V Collection do, and they, at least, do this pretty damn fast, however it's feasible they handle controls a little differently to allow better re-rasterizing effeciency, whereas with the RE SDK it's always a fixed filmstrip, and these can be massive,
plus a VST is a singular device, not a multiple devices all having to be rerendered simultaneously) so all devices would ship with just the original full-size panel and filmstrip artwork. Note this would mean a choice of preset zoom, whether within the rack or as a VST-style pop-up window, not a free zoom with a mouse wheel like a Photoshop image. However, given PH's bare-minimum-standard-for-release implementation history, frankly, I don't see this happening now, it's too urgent an issue given the real demand for it and their need to constantly please, especially given they've already abandoned or backburnered GPU acceleration at least once in the past two years: it wouldn't surprise me at this point if they simply pre-rendered everything once to a fixed appropriate scale for your resolution when you upgrade/install, from the original full-size art with the re-downloaded REs. But they could have set
that up easily enough
anytime in the past eight years, and with a professional designer recreating the old GUIs, at most a week per device, and they've had at least 8 years to update those internally too. So either all those have long since been done or they've not done it at all, and were that the case that'd just speak volumes about some of the decision-making that goes on.
Potentially complicating the matter is in the rush to abandon the 3D format, there could be issues with how they apply the scaling divisor leaving widgets slightly misaligned, as 4096 famously isn't too hot at dividing evenly by 5. (This also suggests a lack of forethought choosing 4096 as the original width too).
Presumably the 3D pipeline can't be rendered wider than the 2D one, because the 2D one must be as high as they now intend to go (which makes sense because as established any potential zoomed-in width probably shouldn't be as wide as the full 3840 resolution width). But many early 2D or 3D to 2D converted products may well have issues with control alignments as it was possible to set values that aren't a position that divides by 5. Maybe the rasterizer handles any of those early discrepancies and there's no issue at all. Impossible to know unless they actually showed us WTF the plan was and we could have checked our work and fixed if the need arose. But they opted not to tell us, repeatedly, over 8 years. And as others have already noted, the DAW world's moved on.
Enhanced by DataBridge v5
Share and download patches!
Join ReasonTalk on Slack!