Julien Bayle

http://julienbayle.net/2012/04/23/myuniverse

 but it is only a global think about my way, and of course it isn't required to answer to my next questions.

Like a galaxy, there will be objects clouds here & there, then a lot of empty spaces.

I'll move a camera into this world, traveling from clouds to clouds.

Each cloud would be a visual & sound experience.

Basically, I'm hesitating about the core architecture design I have to choose.

For many reasons, Max6 is the first natural target I have in mind.

If you'd prefer, I can also create many threads, but at first, I didn't want to pollute too much.

I'm new to this world ; except I made jitter tutus and "played" a bit.

--What would be the steps I should not to miss at first ?

I mean.. should I work on a basic 3D map, creating some specific objects, generalizing progressively the whole stuff ?

I know I can plug myself to jitter 3D part through JS, Java.

I'm comfortable with C++, okay with java.

--Is there a way to use C++ instead of Java ? (The real question could be: is there a benefit to use C++ over Java knowing we can easily edit Java inside Max now?)

--Related to the previous one, should I use Java to initialize & handle all my 3D stuff ?

--If yes, what would be your advice about classes & files separation ? (I mean, one class per feature like: lights, objects movements, etc)

This system would provide me a way to compose & also to make my live performances.

So, in the writing/composition step, I'll need to place objects here & there, to change their attributes (Max attributes BUT specific attributes/properties too), and especially to store all the stuff inside things like ... let's say .. presets.

Naturally, I'm thinking about a flat txt XML file from/to which I'd load/store the map using read/write functions.

I'm still not sure I'd use Max6 for Sound generation.

Maybe, to use another software would preserve Max6 from some performance issues.

This is only a supposition. I'm not sure about that, this is just an intuitive thought.

I could wrap easily a sound system generator using C++ (via OpenFrameworks or another framework handling the basic stuff) and have it connected to Max6 through OSC for instance.

I hope you could give me even some opinions, some ideas at this step of my project.

time is now.
I'm begining my huge project.
The most huge, I guess.

I'm introducing it a very bit here: http://julienbayle.net/2012/04/23/myuniverse but it is only a global think about my way, and of course it isn't required to answer to my next questions.

I need a 3D synthetic world.
In this world, there will be objects.
Like a galaxy, there will be objects clouds here & there, then a lot of empty spaces.
I'll move a camera into this world, traveling from clouds to clouds.
Each cloud would be a visual & sound experience.

So here are some questions.
If you'd prefer, I can also create many threads, but at first, I didn't want to pollute too much.

1/ 3D
I'm new to this world ; except I made jitter tutus and "played" a bit.
--What would be the steps I should not to miss at first ?
I mean.. should I work on a basic 3D map, creating some specific objects, generalizing progressively the whole stuff ?

I know I can plug myself to jitter 3D part through JS, Java.
I'm comfortable with C++, okay with java.
--Is there a way to use C++ instead of Java ? (The real question could be: is there a benefit to use C++ over Java knowing we can easily edit Java inside Max now?)

--Related to the previous one, should I use Java to initialize & handle all my 3D stuff ?
--If yes, what would be your advice about classes & files separation ? (I mean, one class per feature like: lights, objects movements, etc)

2/ Objects Storage
This system would provide me a way to compose & also to make my live performances.
So, in the writing/composition step, I'll need to place objects here & there, to change their attributes (Max attributes BUT specific attributes/properties too), and especially to store all the stuff inside things like ... let's say .. presets.
A preset would be a map.

How would you store this ?
Naturally, I'm thinking about a flat txt XML file from/to which I'd load/store the map using read/write functions.

3/ Sound
I'm still not sure I'd use Max6 for Sound generation.
Maybe, to use another software would preserve Max6 from some performance issues.
This is only a supposition. I'm not sure about that, this is just an intuitive thought.
I could wrap easily a sound system generator using C++ (via OpenFrameworks or another framework handling the basic stuff) and have it connected to Max6 through OSC for instance.

some-question-about-3d-worlds-with-jitter-for-the-hugest-project-of-my-life

My suggestion is to maybe start by taking a look at what others are (or have been doing) along similar lines in the MAx environment, and to that end the first suggestion would be take a look at COSM 

 AFAICT the last release was a Max5version and a while go now (and maybe you want to go a little 'lower level', but even if it is to just get ideas about how you *don't* want to go about it, it could help.

Sounds ... Big...
My suggestion is to maybe start by taking a look at what others are (or have been doing) along similar lines in the MAx environment, and to that end the first suggestion would be take a look at COSM http://www.allosphere.ucsb.edu/cosm/ AFAICT the last release was a Max5version and a while go now (and maybe you want to go a little 'lower level', but even if it is to just get ideas about how you *don't* want to go about it, it could help.


Do not be committed to max. Look at vvvv and processing. Max has "good" graphics, but many say they are not "the best". You can come back into max via osc.

Re c++ versus ava, it's not really a question of performance (any gains would be infinitessimal IMO) but of development speed. Also, "I know c++" and "I know 3d coding" are somewhat different things. I would at least study directx (if on windows) or mac equivalent.

If I did do audio synthesis in max (probably not, to save programming cycles), I would still include an osc/midi output to connect to software and/o hardware synths.

Do not be committed to max. Look at vvvv and processing. Max has "good" graphics, but many say they are not "the best". You can come back into max via osc. 

If I did do audio synthesis in max (probably not, to save programming cycles), I would still include an osc/midi output to connect to software and/o hardware synths.


yes big but it would be even bigger.. it is for many reason the project of my next months/years.

my words will sound better when I'll have some first prototypes to show of course.

COSM. yes it is a nice way. I just would like to know more about object storage, particularly.

I wrote some concepts used in my files, especially the remote rendering stuff.

Even with one computer, and even inside max, as usual, the logic & rendering modules separation can save future headache.

I'd like to use SC for audio stuff, first because I don't know it well and it would be the project to dive deeply into it, secondly because I want to be able to manage synth creation/deletion without boring with poly~ style stuff.

the C++ vs Java is indeed more about programming cycle too.

the Java seems to be the way to go in Max6 since we have that small ide included.

Why would you use preferentially vvvv instead jitter ?

Thanks a lot to both, it makes me thinking deeper to this :)

Sounds ... Big...
My suggestion is to maybe start by taking a look at what others are (or have been doing) along similar lines in the MAx environment, and to that end the first suggestion would be take a look at COSM http://www.allosphere.ucsb.edu/cosm/ AFAICT the last release was a Max5version and a while go now (and maybe you want to go a little 'lower level', but even if it is to just get ideas about how you *don't* want to go about it, it could help.

Hi spectro.
yes big but it would be even bigger.. it is for many reason the project of my next months/years.
my words will sound better when I'll have some first prototypes to show of course.
COSM. yes it is a nice way. I just would like to know more about object storage, particularly.
I wrote some concepts used in my files, especially the remote rendering stuff.
Even with one computer, and even inside max, as usual, the logic & rendering modules separation can save future headache.

Hi jamesson
I'd like to use SC for audio stuff, first because I don't know it well and it would be the project to dive deeply into it, secondly because I want to be able to manage synth creation/deletion without boring with poly~ style stuff.
Not sure yet, but probable.

About visuals.
the C++ vs Java is indeed more about programming cycle too.
the Java seems to be the way to go in Max6 since we have that small ide included.
Why would you use preferentially vvvv instead jitter ?

Thanks a lot to both, it makes me thinking deeper to this :)


(I didn't precise it but I'm using osx, which would give me difficulties to use vvvv on my system, BUT if this was the way to go, I'd use it on my PC)

I'm not particularly knowledgable about video stuff, but I'd consider the approach of using max as a centralized storehouse/control tower that operates at a relatively high level and farms out lower-level or more specialized operations to other software. if your on osx look at Siphon (I think that's what it's called) as a conduit for inter-app video farming. I'd definitely recommend supercollider for audio processing-- it's far more flexible and efficient than max. But then max would be good for UI and doing all the gatekeeping stuff-- maybe also CV and gesture recognition using 3rd party externs...

I'm not particularly knowledgable about video stuff, but  I'd consider the approach of using max as a centralized storehouse/control tower that operates at a relatively high level and farms out lower-level or more specialized operations to other software. if your on osx look at Siphon (I think that's what it's called) as a conduit for inter-app video farming. I'd definitely recommend supercollider for audio processing-- it's far more flexible and efficient than max. But then max would be good for UI and doing all the gatekeeping stuff-- maybe also CV and gesture recognition using 3rd party externs...

+1 to terry, route I would take as well. Re graphics platform, I do not say vvvv is better. I do next to zero graphics, but all the graphics guys I know do not work in jitter.

Cosm was made for max5. max6 has fantastic new features that i think goes beyond cosm. But 1 thing is bothering me with jitter.gl , Objects takes light but can't cast shadows !!!

by sending the message (viewsource) to a [mxj ] object, Max opens a window with the source code.

it isn't eclipse, but it can be very useful.

of course, it is possible to use eclipse (and even XCode) to code java stuff, offering completion etc.

we can also compile stuff inside the same small ide, without going here, there, here, there to test small changes for instance.

My way here will be to build the core engine using java/jitter

A core able to display objects, handle the subject position (=camera position/orientation) in the world.

I'll need a way to compose too = a GUI providing me a way to create object, tweak parameters, then to save the map.

Then, the main part will provide the playing mode, which will be "only" a mode in which I'll move the subject position and I'd be able to tweak stuff with my hardware controller.

I'd love to be able to create lib of visual, audio-visuals objects using java.

My core engine would provide a way to load already made maps. According to those previously designed maps, the core would instantiate required objects (= would create instances of all stuff required in that context)

by sending the message (viewsource) to a [mxj ] object, Max opens a window with the source code.
this is that ide I meant.
it isn't eclipse, but it can be very useful.
of course, it is possible to use eclipse (and even XCode) to code java stuff, offering completion etc.
but this small tiny editor is very nice.

About the use of jitter for graphics.
I'd start with it at least.

My way here will be to build the core engine using java/jitter
A core able to display objects, handle the subject position (=camera position/orientation) in the world.
I'll need a way to compose too = a GUI providing me a way to create object, tweak parameters, then to save the map.
Then, the main part will provide the playing mode, which will be "only" a mode in which I'll move the subject position and I'd be able to tweak stuff with my hardware controller.

I'd love to be able to create lib of visual, audio-visuals objects using java.
My core engine would provide a way to load already made maps. According to those previously designed maps, the core would instantiate required objects (= would create instances of all stuff required in that context)

Maybe you could look into Unity 3D for your visual component. That way you can create a quite goodlooking #D world. The sound you can do with Max or SC (or something else)

I'd probably work the visuals in jitter, at first at least.

I don't see any reason why you couldn't do it in Jitter. You should look at Tarik Barri's work if you haven't already. It's not terribly difficult to create a 3D navigation system using jit.anim.drive with jit.gl.camera. Depending on how you wanted to do it aesthetically, each "cloud" could be represented by a cluster of spheres (jit.gl.gridshape+jit.gl.multiple). You would need to keep track of their positions and compare to the position of the camera for the interaction.

I don't see any reason why you couldn't do it in Jitter.  You should look at Tarik Barri's work if you haven't already.  It's not terribly difficult to create a 3D navigation system using jit.anim.drive with jit.gl.camera.  Depending on how you wanted to do it aesthetically, each "cloud" could be represented by a cluster of spheres (jit.gl.gridshape+jit.gl.multiple).  You would need to keep track of their positions and compare to the position of the camera for the interaction.


Hi Andrew and thanks for your participation here :)

My answers were more to show I'm opened than to avoid to use jitter.

Jitter is the part I know the less and it is the way for me to dive totally (body & mind & soul probably) into it.

Yes I even met Tarik in Leicester at the M4_u convention where I have been invited too to play & lecture (but I only played)

What I'd like to do is a really modular environement.

The current "world" would depend on the map/preset loaded at the startup.

I imagine the system a bit as I described there : 

https://cycling74.com/forums/strategies-around-instantiating-visual-objects-from-java-code

My answers were more to show I'm opened than to avoid to use jitter.
Jitter is the part I know the less and it is the way for me to dive totally (body & mind & soul probably) into it.

What I'd like to do is a really modular environement.
The current "world" would depend on the map/preset loaded at the startup.
I imagine the system a bit as I described there : https://cycling74.com/forums/strategies-around-instantiating-visual-objects-from-java-code

> I do next to zero graphics, but all the graphics guys I know do not work in jitter.

Does that say something about Jitter or about the graphics guys you know? If you're gonna make such statements please underpin 'm with arguments...

> I do next to zero graphics, but all the graphics guys I know do not work in jitter. 

Does that say something about Jitter or about the graphics guys you know? If you're gonna make such statements please underpin 'm with arguments...


Personally, I know a lot of people working with jitter and only jitter for visuals.

Indeed, I also didn't understand this statement but I'm sure the answers/arguments would be very interesting.

Personally, I know a lot of people working with jitter and only jitter for visuals.
Indeed, I also didn't understand this statement but I'm sure the answers/arguments would be very interesting.


you may also want to look at using the physics objects to perform collision detection for you.

techniques such as surrounding your groups of objects and your camera with a jit.phys.ghost shape, will allow you to let the physics engine notify you when the camera encounters a group of objects.

you may also want to look at using the physics objects to perform collision detection for you.
techniques such as surrounding your groups of objects and your camera with a jit.phys.ghost shape, will allow you to let the physics engine notify you when the camera encounters a group of objects.


Hi Robert, and thanks for your answer/ideas.

- design a global Java piece of code instantiating the whole world global stuff.

- design small java piece of code, each one instantiating 1 visual object

The global one would contain array of objects.

It would take care of all properties of all objects instantiated currently.

In a second step, I'll have the current object instantiated and positionned in the 3D world stored in XML preset (probably) ; then, at the launch time, the global stuff would load the preset, then instantiate the required small java stuff in order to display them.

The idea would be to have all objects made on a same structure ; probably:

- setup / update / draw / playSound like methods (considering draw would be unuseful because an object instantiated is drawn til it is hidden/removed or...)

That way, the global stuff would instantiate all, would be also able to instantiate stuff at runtime (pushing back objects in global arrays), then at each turn (master clock involved probably), all method would be invoked for each objects...

Intuitively, I'd like to do that:
- design a global Java piece of code instantiating the whole world global stuff.
- design small java piece of code, each one instantiating 1 visual object

The global one would contain array of objects.
It would take care of all properties of all objects instantiated currently.

The idea would be to have all objects made on a same structure ; probably:
- properties
- setup / update / draw / playSound like methods (considering draw would be unuseful because an object instantiated is drawn til it is hidden/removed or...)

Any strategies to implement this ?
Would it make sense ?


Re graphics platforms and popularity, These folks have all been working for at least 5 years apiece. Regardless, I said I do zero graphics to give thie idea that my knowledge is limited, consequently so is my ability to support my arguments.

Julien, you did not say what you meant by Java IDE - eclipse, or something else?

The reference doc around Java in Max is still the nice : 

http://blog.lib.umn.edu/geers001/compmusprog2007/WritingMaxExternalsInJava.pdf

@Robert, would you help me with my previous question ?

The reference doc around Java in Max is still the nice : http://blog.lib.umn.edu/geers001/compmusprog2007/WritingMaxExternalsInJava.pdf

@Robert, would you help me with my previous question ?


@jamesson: A majority here can probably easily cite 5 experienced visualists who prefer Jitter. Point is, there's no objective way of defining which tool is The Best. The one will be better at this, the other at that. And the 'better' in there is often highly subjective. Yes you can compare frame rates and shader specs but how about ease of use and the like?

@dtr, totally true and agree. In almost all of my projects, I found people saying these word "best" "better" and often mixed with "this is not the best way"

I achieved all, and made things in the meantime. This was and is the important point for me.

People told me a lot about my protodeck controller "you'd better to do this, that, this" and after the result, they wanted their own protodeck :D

Jamesson knows that and advices me about his experience (with his friends) and I really appreciate that.

did someone read that ???? (kidding about the offtopicness of the way of that thread which is nice too!)

@dtr, totally true and agree. In almost all of my projects, I found people saying these word "best" "better" and often mixed with "this is not the best way"
I achieved all, and made things in the meantime. This was and is the important point for me.
People told me a lot about my protodeck controller "you'd better to do this, that, this" and after the result, they wanted their own protodeck :D

Jamesson knows that and advices me about his experience (with his friends) and I really appreciate that.
I decided I'll go with jitter.

Any strategies to implement this ?
Would it make sense ?

Some question about 3D worlds with Jitter for the hugest project of my life