Now I'm having another issue.. Seems when I try to join objects together using a gear joint and a pivot, one of the objects turns 360 degrees before it settles back to the position it should be in.

Not sure what I'm doing wrong.. It doesn't happen all the time, but seems to depend on orientation of the objects. Is there anything I need to keep in mind when doing this? like should the angles be between 0-360, or -180-180?

edit: here's an exmaple: http://1drv.ms/1YvddfG

Seems like setting the angle before joining will mess it up. Any way to get around this?

ahhh! I think I know what is the issue. Seems like when the pointer object(object being positioned to the mouse) is not set to immovable(in the physics), then the joint position gets altered when trying to drag through an object.. But if I set the pointer to immovable, then the joint stays in correct position even if I drag stuff into an object.

Not sure why the difference occurs depending on that setting, but I might be able to work with this now.

So to recap, yeah- I had been doing it like that example, but I didn't have the pointer set to immovable. Having it movable produces weird results when dragging stuff through immovable objects.

I'm having trouble adding the ability to drag an object. I have it so that when mouse down to position an object and have it with a joint to another object that will be dragged, but when I drag it through a wall, the joint gets repositioned so that the objects become separated(joined from a distance), even when I move the mouse back out of the wall.

Any ideas on how to fix?

QuaziGNRLnose , here's an example: http://1drv.ms/1msjDAu

Make sure to run from layout 1.

QuaziGNRLnose , I don't know too much about how alphtesting affects optimizations- I basically just re-enabled it. Your code had a syntax error with it, and a comment saying that having it enabled didn't seem to do anything- so I assumed the syntax error was the reason why it appeared not to do anything. Fixing the syntax error allowed alphatest to get applied.

I think alphatest is useful if you aren't using a shader, since you can discard fragments in the shader to get the same effect.

I wanted to try and get shadows working with alphatest using a custom depth material, like you said.

When I was writing a shader, I wanted to use texture2D to grab color data from a texture, but there wasn't any clear way to specify the texture in the uniforms, so I had to force it to get picked after the shader was loaded from the qfx file.

for example-

I figured out that this worked in the uniform section:

<uniforms>(function(){
	var uniform = {
		uniformCall : function(){
			return {
				texture: { type: 't', value: new THREE.Texture() },
				amplitude: {type:'f', value: 0},
				textureWidth: {type:'f', value: 256.0},
				textureHeight: {type:'f', value: 256.0},
				u_time: {type:'f', value: 0},
				u_resolution: {type:'v2', value: new THREE.Vector2() },
				camPos: {type: 'v3',value: new THREE.Vector3() }
			};
		}
	}
	return uniform;
	})();
</uniforms>[/code:1mgxtn89]
But I wasn't sure how to reference the texture, so I had to add the following in runtime of q3dmodel plugin to get it to work:
[code:1mgxtn89]if(typeof _this.mat.uniforms !== 'undefined'){
			if(typeof _this.mat.uniforms.texture !== 'undefined')_this.mat.uniforms.texture.value = _this.texturebank[0].frames[0].webGL_texture;
			if(_this.matType !== -1 && _this.mat) _this.mat.transparent = ( _this.properties[34] === 0 );
		}[/code:1mgxtn89]

purplemonkey , I have managed to get two viewports working, but the biggest issue I had was that the second camera that you make for it has to have its settings set specifically, since the default camera's settings aren't set the same for new cameras you make.

Quazi, It would be good if new cameras had the same default settings as the default camera..

I have fixed various things on my own, like flipping/mirroring sprites, adding alphatest, and making shaders work.. so if those get fixed in the official plugin, I won't have to reapply my fixes if there's an update.

There's also the bug where if the q3d master is a global object, model's offset parameter get added whenever layout changes, so their offsets become messed up.

— , also in addition to what r0j0hound said, if you need to move it, you can use a separate object to position the other one that shouldn't be affected by forces. r0j0hound helped me with this in the past, here is a snapshot of how I handle it:

the two use different layering groups so they don't collide with each other, and I turn rotation off on the object that follows the other, and give it a high mass value too. Works perfectly.

ign.com/beta/videos/2015/11/19/klang-demo-gameplay

So IGN posted the demo footage of the game! :O

:O nice!

I'm glad I decided to create my own save/load in my current project by writing/reading file instead of relying on the built-in method.

whaaaat?? I get 54% cpu usage for the functions, and about 7-10% without.

Thanks!

Eh.. but the collisions are still there for the parts that aren't updated.

Ashley , If you want to limit the use of the tilemap, you should force it to resize itself to avoid confusion. There is however the possibility that someone would want to update only a section of the tilemap- I don't think you should disregard that. This is an opportunity to make your product better.

It's mainly just odd that the tiles outside of the updated area remain visible, as well as their collisions- so why not their tile number be accessible as well? It just seems like an oversight. Something just isn't right with it. I also don't think it is good to just assume nobody will ever update just part of the tileset and expect the rest to go unused- that sort of thinking limits creativity.

edit: I guess I could make a plugin that loads in a section with offsets, etc.. I think I'll do that for now.