No GUI there… just testing viewports. All freeCams in #28, but PG #29 uses an arcCam as over-laid viewport/cam6.
The camera6/viewport6 is laid atop the other 5 viewports. (main screen only looks-like 3 viewports, but it is actually 5. Blue lines are viewports, too)
Now, if we could live-position and live-set-size/live-scale viewport 6… AS IF it were a GUI image control (possibly within a GUI container/stackpanel/grid)… then that would work, yes? No renderTargetTexture used.
Just thinkin’ up strange ideas… not sure if useful. GUI viewportControl, sort-of.
But viewports might not be “live” or “dynamic”. Early tests say YES, it IS size/position dynamic.
In theory, it SHOULD be able to “act” like a GUI control. Canvas/engine re-sizings COULD be trouble.
Gijs… WELL DONE! Cooooool. I haven’t yet earned my GuiControlBuilder’s certificate… but… is this new control… properly API-certified for being an “official” GUI Control? Does it meet all criteria for being a USDA-certified prime beef widget? Proper observers/notifies, etc?
Would .value be the viewport object, and onValueChanged is active? (I should just go inspect Giji’s control-code, eh? But, I’m not really qualified to determine if it is “proper” or not.)
If it is all proper… and GUI Control criteria is met… I say PR that puppy into Userville (if Gijs is willing). Fun/useful control, perhaps.
Again, nice job, G-willickers! You GUI Control-makers are SUCH heroes of mine. Sigh. Someday, I’m going to be good enough to make one. WingyWidget 1.0. Doesn’t do anything useful, but it’s fun as hell to click-on. My kind of control… an out-of-control control.
THE CODE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
All those custom controls are flawed; they’re interfering with the scene/camera in one way or another, and they don’t behave like real controls… but they’re fun to click on
If you want to speed up your scene and reduce GPU tasking, then you should be using power of 2 textures whenever you can. It’s far more efficient to avoid calling a very large non power of 2 image when you only need a small portion of the resolution. I mention this as I don’t know if you’re using power of 2 and designing your scene and texture prior to texture creation. If you are, then you’re way ahead of most devs on this forum. I just know that this needs to be spoken of more often as devs appear to always look for new tools; often ignoring good practices. Either way, I hope others look at adopting core practices necessary to scene and hardware optimization.
I know this doesn’t answer your question, but I’ve spent time on other topics recently which can be answered through scene and asset design. As for a RenderTargetTexture, what is your current need? It sounds as though you’re exploring right now which is awesome. We all should do this far more and not always wait until crunch time to explore functions, methods, and processes. It would help greatly if we could get a better understanding of your end goal. Just a general usage description would be helpful.
I see this all of the time… elements such as meshes and more importantly textures are created and applied without any though given to scene optimization in advance. I recommend using this scene as a benchmark to explore GPU and memory usage. I personally advise that you set up different configuration of your texture(s) and record your GPU and memory usage. Once you do this, you’ll have a much better understanding of texture optimization in WebGL.
It’s a HUGE deal and where many devs fall short. I always recommend designing your scene for your target hardware and software. It takes me back to game development for desktop and consoles where if we didn’t design our scenes prior to asset creation, we would never have released a single game. I would love to see a change in the community; where developers turn back to good practices in scene creation and rendering. The hardware is virtually the same with all of the same issues… but few devs are taking the lessons of the past into consideration. I simply don’t understand where the communication of this is lost. I know I bring it up as often as possible.
I also have the same problem with you, there is more than one camera in the same scene, in addition to the main camera’s other camera will grab the scene render elements in different renderTexture above, and each camera can separate operation, I want to know, I should how to do it, I have many don’t understand, now my effect is had, but my camera does not move, so I don’t know how can I next