PDA

View Full Version : three.js particles vanish



wwfc
03-20-2015, 12:52 PM
Hi,

I have a problem with three.js. i have two particle system set ups that seem to be conflicting with each other.

The first scene loads up without problem, but when the second set loads the first set of particles vanish. This wouldn't be too confusing if it weren't for the the fact that the rest of the first scene is still appearing in the entire set up.

Is there an easy way to rename or call in the two sets of particles?

I've looked around but can't find a ref to this and three.js doesn't seem to have any dedicated forum.

the one thing that i think might be causing this is the PARTICLE_COUNT call - which features in both scripts...

in one it is


var PARTICLE_COUNT = 15000;
var MAX_DISTANCE = 1500;
var IMAGE_SCALE = 5;
followed by

for(var i = 0; i < PARTICLE_COUNT; i++) {
geometry.vertices.push(new THREE.Vertex());
var star = new Star();
stars.push(star);
}
and the second


AUDIO_FILE = 'songs/zircon_devils_spirit',
PARTICLE_COUNT = 250,
MAX_PARTICLE_SIZE = 12,
MIN_PARTICLE_SIZE = 2,
GROWTH_RATE = 5,
DECAY_RATE = 0.5,

BEAM_RATE = 0.5,
BEAM_COUNT = 20,

GROWTH_VECTOR = new THREE.Vector3( GROWTH_RATE, GROWTH_RATE, GROWTH_RATE ),
DECAY_VECTOR = new THREE.Vector3( DECAY_RATE, DECAY_RATE, DECAY_RATE ),
beamGroup = new THREE.Object3D(),
particles = group.children,
colors = [ 0xaaee22, 0x04dbe5, 0xff0077, 0xffb412, 0xf6c83d ],
t, dancer, kick;

followed by


dancer = new Dancer();
kick = dancer.createKick({
onKick: function () {
var i;
if ( particles[ 0 ].scale.x > MAX_PARTICLE_SIZE ) {
decay();
} else {
for ( i = PARTICLE_COUNT; i--; ) {
particles[ i ].scale.addSelf( GROWTH_VECTOR );
}
}
if ( !beamGroup.children[ 0 ].visible ) {
for ( i = BEAM_COUNT; i--; ) {
beamGroup.children[ i ].visible = true;
}
}
},
offKick: decay
});

dancer.onceAt( 0, function () {
kick.on();
}).onceAt( 8.2, function () {
scene.add( beamGroup );
}).after( 8.2, function () {
beamGroup.rotation.x += BEAM_RATE;
beamGroup.rotation.y += BEAM_RATE;
}).onceAt( 50, function () {
changeParticleMat( 'white' );
}).onceAt( 66.5, function () {
changeParticleMat( 'pink' );
}).onceAt( 75, function () {
changeParticleMat();
}).fft( document.getElementById( 'fft' ) )
.load({ src: AUDIO_FILE, codecs: [ 'ogg', 'mp3' ]})

Dancer.isSupported() || loaded();
!dancer.isLoaded() ? dancer.bind( 'loaded', loaded ) : loaded();

bit of a "needle lost in a haystack" i know...

but maybe someone can see the error of my ways!!!

jscheuer1
04-04-2015, 04:58 PM
On the same page and in the same context? If so, of course they will usually conflict. I don't know what you know about scope (aka context). But basically if you declare a variable to be one thing, and then change it to another value, it almost always will change the result of code that depends upon the first value. And, it can get worse - say, if the output is written to the page in the same place. In that case, usually the new output will overwrite or otherwise mess up the old output.

Often the solution is to change the code so that these common variables now have unique names (like PARTICLE_COUNT_1 and PARTICLE_COUNT_2 *) and/or to provide unique elements** on the page for their respective output.

However, in order to diagnose this effectively, we would need to see three pages:

1 - a page where the first code is working as expected by itself.
2 - a page where the second code is working as expected by itself.
3 - a page where the two codes combined are causing the problem.

If you want more help and are serious about this, please set these three pages up somewhere you can provide a link to them so we can have a look.


*When employing this method, change (in this case) PARTICLE_COUNT to PARTICLE_COUNT_1 throughout the entirety of the first code and to PARTICLE_COUNT_2 throughout the entirety of the second code. Do a similar thing with any other variable names the two codes may share in common.

**Since it's not clear if or if there are, where any output elements for these codes might be, I would have to see working examples to be more specific. The second one looks like it might use the "beamGroup.children" to represent the output (particles I guess in this case). There doesn't seem to be any output from the first code, at least not the part that is shown in your post.