veaseyc

Has anyone figured out a way to map screen to 3d world without using javascript?

I am trying to make an interface for a pluggo plugin. Jitter JS doesn't seem to draw to a screen in the pluggo environment, and JSUI is out of the question for other reasons. Also I don't want to use jit.gl.handle because (a) I want the default transform to be position not rotation (b) the mod key is overridden by a pluggo menu

I don't mind coding some matrix math, but I need a step in the direction; is it possible?

Has anyone figured out a way to map screen to 3d world without using javascript? 

screen-to-world-by-hand

Have you looked at the JitterHitTest example in the jitter/javascript folder?

On Jun 7, 2006, at 4:54 AM, Wesley Smith wrote:

> Have you looked at the JitterHitTest example in the jitter/ 

This uses javascript's screentoworld method, fwiw. In Jitter 

1.5.3/1.6, screentoworld and worldtoscreen will be exposed to the 

patcher via jit.gl.render, however for the meantime, you can just 

make a simple Javascript which wraps jit.gl.render. You can of course 

perform all the matrix math necessary to accomplish this, and I know 

at least one person whose done this with jit.la.*, but your math 

I've taken 15 minutes to build a js wrapper workalike for 

jit.gl.render and an example patch which uses it (at bottom). Similar 

    render.freepeer(); // when editing JS file, explicitly free c peer 

render = new JitterObject("jit.gl.render",contextname);

    var a = arrayfromargs(arguments);

    var w = render.screentoworld(a);    

    var s = render.worldtoscreen(a);    

    //pass off all other messages to the movie object

    if (Function.prototype.isPrototypeOf(render[messagename])) {

        render[messagename](a);    

        if (messagename=="swap"||messagename=="drawswap")

            outlet(0,"bang");

        if (messagename.length>3&&messagename[0]=='g'&&messagename[1] 

            var attrname = messagename.slice(3);

            var rv = render[attrname];

             outlet(1,attrname,rv);    

            render[messagename] = a;    

> Have you looked at the JitterHitTest example in the jitter/ 
> javascript folder?

This uses javascript's screentoworld method, fwiw. In Jitter  
1.5.3/1.6, screentoworld and worldtoscreen will be exposed to the  
patcher via jit.gl.render, however for the meantime, you can just  
make a simple Javascript which wraps jit.gl.render. You can of course  
perform all the matrix math necessary to accomplish this, and I know  
at least one person whose done this with jit.la.*, but your math  
chops will need to be up to snuff.

I've taken 15 minutes to build a js wrapper workalike for  
jit.gl.render and an example patch which uses it (at bottom). Similar  
can be done for any Jitter object.

/**************************
	begin jsrender.js
***************************/

if (jsarguments.length>1)
	contextname = jsarguments[1];

if (render)
	render.freepeer(); // when editing JS file, explicitly free c peer  
before allocating another one

function screentoworld()
{
	var a = arrayfromargs(arguments);
	var w = render.screentoworld(a);	
	outlet(1,"screentoworld",w);
}

function worldtoscreen()
{
	var a = arrayfromargs(arguments);
	var s = render.worldtoscreen(a);	
	outlet(1,"worldtoscreen",s);
}

function bang()
{
	render.drawswap();	
	outlet(0,"bang");
}

/**************************
	end jsrender.js
***************************/

I appreciate the effort, but it doesn't work when compiled to a plugin and loaded into an external vst host (Nunendo 3 in this case).

Further test suggest to me that the jitter js object constructor isn't working in external vst hosts.

I tried making a plugin with nothing but a js object and the following text:

var mult = new JitterObject("jit.la.mult");

"Javascript reference error: JitterObject is not defined, line 0"

I included the external in the build script, and jitlib file. Have you known anyone to get Jitter JS loaded in an external VST host?

You need to *not* include jitlib in the build script. This is not 

supported for libraries which are not externs.

You *do* need to place jitlib in CFM support.

You *do* need to place jsjitter in the jsextensions folder for 

Pluggo, which depending on which version of pluggo will be /Library/ 

Application Support/Cycling 74/ or the Pluggo Support folder 

(wherever that is...I don't know off the top of my head).

You *do* need to place any additional exerns used (such as 

jit.gl.render in this case) in either the build-script (and the 

"nostrip" file so that this file remains when building your plugin; 

for more info please consult pluggo developer docs), or simply in the 

Pluggo Support folder which is one of the two places mentioned above.

If you wish to use other necessary Jitter items such as Cg.framework, 

Java support, or shader files, please follow the instructions in 

Appendix D of the Jitter 1.5.2 Manual, but place in the appropriate 

Pluggo support folder rather than the Standalone bundle.

You need to *not* include jitlib in the build script. This is not  
supported for libraries which are not externs.

You *do* need to place jsjitter in the jsextensions folder for  
Pluggo, which depending on which version of pluggo will be /Library/ 
Application Support/Cycling 74/ or the Pluggo Support folder  
(wherever that is...I don't know off the top of my head).

You *do* need to place any additional exerns used (such as  
jit.gl.render in this case) in either the build-script (and the  
"nostrip" file so that this file remains when building your plugin;  
for more info please consult pluggo developer docs), or simply in the  
Pluggo Support folder which is one of the two places mentioned above.

If you wish to use other necessary Jitter items such as Cg.framework,  
Java support, or shader files, please follow the instructions in  
Appendix D of the Jitter 1.5.2 Manual, but place in the appropriate  
Pluggo support folder rather than the Standalone bundle.

jsjitter is in the cycling '74/jsextensions folder, but not in the pluggo support folder, so i'll try that. Everything else you mentioned is in place. Except I have not tried the "nostrip" file, which from reading the docs appears to be for older versions of pluggo anyway.

The reason I could never find Appendix D is the following:

Jitter 1.5 documentation only (Mac version)

on both the the downloads and documention menu delivers possibly an older version without Appendix D. 

The link on the website: 
Jitter 1.5 documentation only (Mac version)

on both the the downloads and documention menu delivers possibly an older version without Appendix D. 
Thanks again.


On Jun 7, 2006, at 8:16 PM, veaseyc wrote:

> jsjitter is in the cycling '74/jsextensions folder, but not in the 

> pluggo support folder, so i'll try that. Everything else you 

> mentioned is in place. Except I have not tried the "nostrip" file, 

> which from reading the docs appears to be for older versions of 

Okey doke. Been years since I've made a pluggo.

> The reason I could never find Appendix D is the following:

> Jitter 1.5 documentation only (Mac version)

Sorry but you need to download the 1.5.2 installer to get the current 

>
> jsjitter is in the cycling '74/jsextensions folder, but not in the  
> pluggo support folder, so i'll try that. Everything else you  
> mentioned is in place. Except I have not tried the "nostrip" file,  
> which from reading the docs appears to be for older versions of  
> pluggo anyway.

> The reason I could never find Appendix D is the following:
>
> The link on the website:
> Jitter 1.5 documentation only (Mac version)

Sorry but you need to download the 1.5.2 installer to get the current  
version with Appendix D.

..Library: Application Support: C74 Plug-in Support: jsextensions

did the trick, js jitter working in an external plugin host.

Now I can use the screentoworld, but I am a bit unsure if it can help me.

I am making 3D audio panning plugins, and want them to have a central graphical hub. The idea is whenever someone loads a panning plugin, a little sphere will be added to the graphic plugin, which in turn allows one to either position the audio visually with the mouse/keyboard or with the panning plugin cartesian/polar coordintates.

I have everything working, except that when the object is not at z=0 or the world is rotated, the mouse (I use simple 2d mapping based on the window size) of course is not lined up correctly in relation to the graphic. I see the JitterHitTest example on how to get the position of the torus, but then it uses jit.handle to position them. I can't use jit.handle because the the Z enabling modifier key is being overtaken by pluggo. Also I would like position to be the default mouse activity not rotation. Can this be modified so that jit.handle is not being used?

Currently the way I am working this plugin system out is that I have placed a jit.gl.gridhape object inside each panning plugin. The name of the render destination is the same as render and window in graphic plugin so it works out. I know there are other ways to go about it, but this seems to give me good results. Does doing it this way still allow me get it's position through the screentoworld function?

..Library: Application Support: C74 Plug-in Support: jsextensions 

Now I can use the screentoworld, but I am a bit unsure if it can help me. 

I am making 3D audio panning plugins, and want them to have a central graphical hub. The idea is whenever someone loads a panning plugin, a little sphere will be added to the graphic plugin, which in turn allows one to either position the audio visually with the mouse/keyboard or with the panning plugin cartesian/polar coordintates. 

I have everything working, except that when the object is not at z=0 or the world is rotated, the mouse (I use simple 2d mapping based on the window size) of course is not lined up correctly in relation to the graphic. I see the JitterHitTest example on how to get the position of the torus, but then it uses jit.handle to position them. I can't use jit.handle because the the Z enabling modifier key is being overtaken by pluggo. Also I would like position to be the default mouse activity not rotation. Can this be modified so that jit.handle is not being used? 

screen to world by hand ?