How to have a scrolling renderer in ThreeJS? - html

I'm using the OrtographicCamera.
A canvas is declared in HTML and I pass it to the renderer as shown below:
var canvas = document.getElementById("canvas")
var width = canvas.clientWidth;
var height = canvas.clientHeight;
renderer = new THREE.WebGLRenderer({
antialias: true,
canvas: canvas
});
renderer.setClearColor(0xf0f0f0);
renderer.setPixelRatio(window.devicePixelRatio);
renderer.setSize(width, height);
The problem is that the cubes I'm adding to the scene are being cut.
The scene is growing and has a height bigger than the available viewport's height.
I'd like to have scrollbars so that I can move to the bottom of the canvas and see all the cubes without having to zoom.
See the screenshot:
HTML
<div id="container">
<canvas id="canvas"></canvas>
</div>
CSS
#canvas
{
width: 100%;
height: 100%;
}
Any advice is really appreciated.

You have two things going on. The first is that the canvas needs to be larger than the client window to get scrollbars to show up. The exact size depends on your needs, but try doubling it from what you have now.
The second issue is going to be that the camera itself has left, right, top, and bottom (as well as near and far) planes that define the area within the camera's view. Increase those values when setting up the camera to get more of the scene visible in the canvas. If your width is fine, you may be able to only increase the top/bottom instead.
https://threejs.org/docs/api/cameras/OrthographicCamera.html

I used orbitcontrols and managed to get what I wanted, that is, being able to see the hidden objects in the scene. The user just have to press arrow down and arrow up to move the camera down\up.
No need to fiddle with the canvas element at all. That's good because controlling the canvas size in CSS is a bit hard and much more when there's scrolling involved and having it attached to ThreeJS renderer.
https://github.com/mattdesl/three-orbit-controls

Related

Problem- can't get the accurate coordinates of mouse on page resize, when using html5 canvas

I wanted to create this Pixel Effect from Frontend Expert.
Although I was able to implement the entire pixel effect on a full screen canvas:
const canvas = getElementById('canvas');
canvas.height = window.innerHeight; // Gives the canvas height of fullscreen
canvas.width= window.innerWidth; // Gives the canvas width of fullscreen
and got the coordinates of the mouse pretty easily
const mouse = {
x: undefined,
y: undefined
}
canvas.addEventListner('mousemove', function(e) {
mouse.x = e.x;
mouse.y = e.y;
}
About now the canvas width and height was equal to that of the document, therefore, it was pretty easy to get the exact coordinates of the mouse.
But when I tried to implement it with 800px X 400px dimensions and used a flexbox with it (like shown in the website) my mouse coordinates got completely messed up and I spent hours in fixing but wasn't able to get the accuracy as shown in the above website. Also there were some issues related to resize.
I would like to know how can I preserve the mouse accuracy.
Your help is much appreciated.
I believe when you use e.x and e.y, even though used in an event listener for tha canvas, they return the mouse coordinate relative to the top-left pixel of the entire page, not just the canvas. If by messed up, you mean that anywhere you click, the pixel effect is offset in some constant direction, this may be your issue and you should replace e.x and e.y with e.clientX and e.clientY. The ‘client’ in e.clientX refers to which element the listener is for and specifies to give event coordinates relative to that element instead of the page. If it is messed up in some other way, then I don’t think I have an answer for that.

HTML canvas best practices for resizing

Doing a simple 2d physics engine with HTML5 Canvas (collisions,graphing). I want a full screen canvas with a header navbar. How can I create this layout and handle resizing correctly?
I have tried several solutions:
One involved programatically resizing the canvas to fill its container onload() and onresize(). Canvas contents stay the same.
Another involved a responsive canvas with percents whose contents shrunk as the canvas shrunk.
Can anyone help lead us to the holy grail? The most important question is your opinion about canvas resizing best practices (should we do it?). If so, what about the debate between resizing the canvas pixels and media queries vs flex/percents vs javascript container measuring, etc.
Example/Attempts:
Example-1:
Here is the Javascript code which I used in v1 of my mock up. The corresponding HTML was just a basic document with a header and a 100% container with the canvas inside the container and being set to fill the container.
window.onload = function(){
init();
};
window.addEventListener("resize", init);
function init(){
console.log("init");
initCanvas();
drawCircle();
}
function initCanvas() {
var content = document.querySelector(".content");
var canvas = document.querySelector(".myCanvas");
canvas.width = content.clientWidth;
canvas.height = content.clientHeight;
}
Example-2:
This CodePen is an example of the resizing canvas that I made. It still retreats up under the navbar during extreme resizing though.
Resizing
It will depend on how you are rendering.
requestAnimationFrame is best practice.
Generally best practice to make any changes to the DOM is to use requestAnimationFrame to ensure that changes are presented in sync with the display hardware's refresh. requestAnimationFrame also ensure that only when the page is visible will the changes be made. ie (if the client switches tabs to another tab, your tab will not fire any requestAnimationFrame events)
It is also best to keep the canvas resolution as low as possible. Keeping the canvas at a resolution higher than the display means you will be doing a lot of needless rendering on portions that are off screen, or if you are scaling the canvas via CSS the down or upsampling can result in a variety of unwanted artifacts.
The problem with the resize event.
The resize event is triggered by a variety of sources, OS events that change the window size, mouse events, or from Javascript. None of these events are synced to the display, and some resize events can fire at very high rates (mouse driven resize can fire 100+ times a second)
Because resizing the canvas also clears the image data and resets the context state, each resize requires a re-rendering of the content. The rapid firing rate of the resize event can overwork the thread and you will start to lose events , the page will feel laggy and you can get parts of the page that are not updated in time for the next display frame.
When resizing you should try to avoid resizing when not needed. Thus the best time to resize is via a requestAnimationFrame callback.
Realtime rendering
If you are rendering in realtime then the best way to resize is to compare the canvas size to the container's or window size at the start of every render frame. If the sizes do not match then resize the canvas.
// no need for a resize event listener.
function renderLoop(){
// innerWidth / height or containor size
if(canvas.width !== innerWidth || canvas.height !== innerHeight){
canvas.width = innerWidth;
canvas.height = innerHeight;
}
// your code
requestAnimationFrame(renderLoop);
}
requestAnimationFrame(renderLoop);
Static renders
If you are rendering infrequently or as needed. Then you may be best off to keep a canvas at a standard resolution offscreen and use a resizable canvas on screen to render a view of the offscreen canvas.
In that case you keep a main loop alive that will check a semaphore that indicates that there is a need to update the view. Anything that changes the canvas will then just set the flag to true.
const mainCanvas = document.createElement("canvas");
const mCtx ...
const canvas = document.getElementById("displayCanvas");
const ctx ...
// when updating content
function renderContent(){
mCtx.drawStuff...
...
updateView = true; // flag the change
}
// the resize event only need flag that there is a change
window.addEventListener("resize",()=> updateView = true );
var updateView = true;
function renderLoop(){
if(updateView){
updateView = false; // clear the flag
// is there a need to change display canvas resolution.
if(canvas.width !== innerWidth || canvas.height !== innerHeight){
canvas.width = innerWidth;
canvas.height = innerHeight;
}
// draw the mainCanvas onto the display canvas.
ctx.drawImage(mainCanvas, viewOrigin.x, viewOrigin.y);
}
requestAnimationFrame(renderLoop);
}
requestAnimationFrame(renderLoop);
In your case using the above method (even for realtime) gives you better control over what part of the canvas content is seen.
CSS
Some poeple consider that CSS is the only place any type of visual content should be changed. The problem with the canvas is that CSS can not set the canvas resolution so if you use CSS you still have to set the canvas resolution.
For the canvas I do not set any CSS sizes and let the canvas resolution properties set the display size canvas.width=1920; canvas.height=1080; I can not see the point of having having to set the CSS width and height when there is no need to
Note: If you do not use requestAnimationFrame you will need to set the CSS size as you can not guarantee the canvas resolution will be set in time for the next refresh, while auto CSS updates (eg canvas.style.width="100%") will change in sync with the display device.
It works, you could check it with element inspect.
And I was thinking you wanted change the style width/height of canvas, not the width or height of canvas, they are quite different.
The width or height of canvas would just affect the ratio of things you draw on the canvas. And the CSS style width or height could change the display size of the canvas.

Does an offscreen canvas have as much "space" as a normal one?

I have a situation similar to this question about copying data between canvases, but in my case I think I'm running into issues with the canvas engine itself and I'd like some understanding/guidance on what I might be doing wrong.
I'm creating an offscreen canvas with the same width and height as the onscreen canvas.
#offscreenCanvas = document.createElement('canvas')
# assign same dimensions as onscreen canvas
#offscreenCanvas.width = canvas.width
#offscreenCanvas.height = canvas.height
Then I'm drawing from the offscreen canvas to the onscreen one like this:
# grab the width and height of the canvas
{ width, height } = #canvasElement
{ x, y } = offset
# copy image from layer into canvas
#context.drawImage
#offscreenContext.canvas, -x, -y, width, height, -x, -y, width, height
The offset is also the argument into a function which translates the "live" canvas context before all this drawing takes place.
#context.save()
#context.translate(#offset.x,#offset.y)
#renderer.draw(world, #offset)
#context.restore()
In other words we're trying to grab the section of the offscreen context that corresponds to the translated offset of the on-screen context.
This has some issues. When the offset moves the 'camera' far from the origin, you encounter the 'edges' of the offscreen canvas.
Note that when I do the same rendering operations against the onscreen canvas, the elements are fine.
It seems like the offscreen canvas isn't quite as good about handling drawing off its "edges" the same way the canvas is (silently ignores drawing commands outside of its defined region.) In other words, the offscreen canvas doesn't seem to reflect any drawing I've done above or to the left of [0,0] (or alternatively, below or to the right of [width,height].) Are there ways of accommodating this?
Things I've tried:
adjusting up the width and height of the offscreen canvas (this unfortunately seems to have a hard-to-predict impact on coordinates)
I've been able to address the issue by indicating a larger offscreen canvas size. The issue with coordinates seemed to be about Isomer's origin position (which you can override by passing in a different origin.)
A minor note: as per MDN's article on canvas optimization you need to ensure the coordinates and dimensions you pass to drawImage aren't floating point (i.e, call Math.floor on them.) I was running into odd antialiasing artifacts without this.

HTML Canvas scale

I've started experimenting with drawing on a Canvas object. In the past my exposure to a Canvas has been centered (NPI) around image manipulation, so I'm moderately familiar with its coordinate system and transformation process. I'm working with a test canvas that has a screen dimension of 30 X 30. After getting a handle to the 2D context I issue one call:
ctx.fillRect(0,0,10,10);
produces a little black spec about the size of a pin head in the upper left corner. To get the rectangle to be of any size, say something approximate 1/4 of the canvas, requires an adjustment to:
ctx.fillRect(0,0,200,200);
So, how has this canvas's scale been skewed? Yes, I guess I could "de-scale" it back to something resembling normal, but I'd like to figure out what's causing this in the first place. I've disabled Jquery thinking it might be interfering somehow, but that did not help.
Any ideas?
UPDATE:
The canvas is added to the dom along these lines:
<canvas id='foo_" + self.groupIndex + "' class='hCanvasClassName'>"
whereby the CSS defines the width at 100% and the height is assigned by JS code.
You didn't show the code for this, but it sounds as you have applied the size for the canvas using CSS and not directly on the element which would explain why it scales down.
You need to do this:
<canvas width="30" height="30" id="myCanvas"></canvas>
If you did this:
<canvas style="width:30px;height;30px;" id="myCanvas"></canvas>
what will happen is that the canvas element uses a default size (300x150, see here: http://jsfiddle.net/AbdiasSoftware/CfMNf/) and then you scale that down to 30x30 by css which means everything now drawn to the canvas will be scaled accordingly.

html5 canvas scaling without specifying dimensions

I've just started working with the html5 canvas element.
I'm using the latest firefox and chromium browsers. And so far, they're
responding alike.
What I'm trying to achieve is scaling of an image without having to
specify the canvas or image drawing sizes. I'd like the canvas to fill
the browser window, and for the image to fill the canvas without
specifying any sizes. And to readjust canvas and its image on the
fly when the user adjusts the browser's frame.
The mansion pic that I'm testing with is 4284x2844.
I've managed to achieve dynamic scaling, but there's a problem...
if I don't specify sizes the image becomes blurry.
This is my first stackoverflow question and I haven't conquered the
formatting. So, please take a look at the small amount of code over
at pastebin:
http://pastebin.com/88faqJUx
Thank you for your help.
I found the solution...
Adding two lines, with no other changes, did the trick, though at this point I'm not exactly sure
why it was originally failing, but thoroughly happy to move on...
<canvas id="taba_main_canvas">
Your browser does not support the canvas element.
</ canvas>
<script type="text/javascript">
var main_canvas=document.getElementById("taba_main_canvas");
var cxt=main_canvas.getContext("2d");
// adding these next two lines solved the blurriness issues
//Set the canvas width to the same as the browser
main_canvas.width = window.innerWidth;
main_canvas.height = window.innerHeight;
var img=new Image();
<!-- mansion pic 4284x2844 -->
img.src="images/mansion_3344.png";
img.onload = function()
{
<!-- use the graphics full size and scale the canvas in css -->
cxt.drawImage(img,0,0,main_canvas.width,main_canvas.height);
}
</script>
Just one tiny little problem, the vertical size of the image is apparently just a few lines taller
than the canvas and so I get a vertival scrollbar. Dragging the browser window taller, which normally
would eliminate the vertical scrollbar has no effect. I've tried manipulating the canvas or image height
in the code, but that didn't change anything.
Still, having the image look clean is a big win. I'm moving on for the moment and will revisit this
later.
The other way to do this is to latch on to the document onresize event and resize the canvas by using window.innerWidth and window.innerHeight or some such thing. I've used it that way myself, but that was for something which I didn't care about IE support - see W3C DOM Compatibility - CSS Object Model View at quirksmode for info about browser support. Note also that the scrollbar width is included in innerWidth and innerHeight; if your page may need scrolling, you may wish to do something like subtract 20 and pad the containing element with a suitable background colour.
I presume that you're not just trying to draw an image - if you were just doing that, <img> would be a much better match.
Edit: jQuery has $(document).width(); and $(document).height(); which seem to get the right figures. Another edit: actually they're wrong; they're the document width and height, not viewport width and height, so I think innerWidth and innerHeight may be all there is.