 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I've been working on a system to make it possible to easily composite 3D
sound for POV-Ray animations. By 3D sound I mean sound which is in stereo
and which also automatically gets louder when the source of the sound gets
closer to the camera. Dobbler effect is also implemented.
My first test animation can be seen/heard in povray.binaries.animations.
http://news.povray.org/povray.binaries.animations/thread/%3C414adb2a%40news.povray.org%3E/
The system works this way: In your POV-Ray scene you set up the sound with
some macros. (An example is shown together with the test animation.) An
include file then writes a data text file to the disc while your scene is
rendering frame by frame. The text file contains data about where the camera
and the sources of sound are at each point in time, and which wav-files to
play from which sources at which times. This text file can then be read by a
java program that I've written which then creates an output stereo wav-file.
However, designing the system in a way which makes it both flexible and easy
to use requires some thought. The system as it is now is functional but
rather crude. Therefore I could really need help with designing the system
in a good way. I need help from people experienced with writing complex
systems of macros, java programmers and people who have a habit of thinking
"ah, the syntax of this feature could have been designed in a much cleverer
way". Here of some of my design problems:
- How should the user specify the sound information?
- How can the system be made to work both for clock-based animations and
frame-based animations (typically simulations with I/O)?
- How should the specification of the data file be? The current one is
somewhat a mess.
- How does one make a java program easy to use by others who don't know what
to do with .java and .class files? There should be a good solution to this,
but I'm not experienced in this area.
- How can I make the java program more clean and well-structured? How does
one write a text parser? (The current one is a hack.)
If there is sufficient interest, I'll upload the files somewhere for others
to look at.
Rune
--
3D images and anims, include files, tutorials and more:
rune|vision: http://runevision.com
POV-Ray Ring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Among other things, Rune wrote:
> Dobbler effect is also implemented.
It's "Doppler". You have the same mistake in the code in p.b.a.
--
light_source{9+9*x,1}camera{orthographic look_at(1-y)/4angle 30location
9/4-z*4}light_source{-9*z,1}union{box{.9-z.1+x clipped_by{plane{2+y-4*x
0}}}box{z-y-.1.1+z}box{-.1.1+x}box{.1z-.1}pigment{rgb<.8.2,1>}}//Jellby
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jellby wrote:
> Among other things, Rune wrote:
>
>> Dobbler effect is also implemented.
>
> It's "Doppler". You have the same mistake in the code in p.b.a.
You're right. Thanks you.
Rune
--
3D images and anims, include files, tutorials and more:
rune|vision: http://runevision.com
POV-Ray Ring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Well, let's have a look at your questions:
> - How should the user specify the sound information?
Depends on what you mean with "sound information". If it's just specifying a
sound with a given volume and its location, that would be real easy. Maybe a
single parameter could store something like global-scale, e.g. how much one
POV-Unit is supposed to be in meters or such, to properly calculate the
doppler-effect. I'd guess tracking the relative position of the sound to the
camera would supply all the data needed to calculate volume and doppler.
> - How can the system be made to work both for clock-based animations and
> frame-based animations (typically simulations with I/O)?
In my animations, I define a variable Animation_Time, which I use to tell
different macros how long the scene is in seconds. Especially for
physics-simulation this is useful, as balls etc drop as much in 10 frames as
in 100 frames. My clock always run from 0 to 1. With the seconds and the
frames I can simply calculate the time-interval and voila: clock-based and
frame-based aren't a problem anymore.
> - How should the specification of the data file be? The current one is
> somewhat a mess.
Not quiet sure what you mean with the data file. The POV-Source?
> - How does one make a java program easy to use by others who don't know
what
> to do with .java and .class files? There should be a good solution to
this,
> but I'm not experienced in this area.
Me neither. But if your app just parses the data-file and outputs a
wave-file, a simple batch-file which runs the app should be sufficient.
> - How can I make the java program more clean and well-structured? How does
> one write a text parser? (The current one is a hack.)
Ah, well, I'd need to have a look at it to say anything about that, but I'm
not *that* experienced either.
I hope some of my comments are of some help. I'd like to have a look and
all, but I'm currently tied up working on an IRTC entry that needs to be
finished, but I'll be happy to participate in a few brainstorming sessions
or discussions, either here or via email. But maybe off-topic would be a
better area to discuss things then, in order not to junk the groups here.
Regards,
Tim
--
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tim Nikias wrote:
>> - How can the system be made to work both for clock-based animations
>> and frame-based animations (typically simulations with I/O)?
>
> In my animations, I define a variable Animation_Time, which I use to
> tell different macros how long the scene is in seconds. Especially for
> physics-simulation this is useful, as balls etc drop as much in 10
> frames as in 100 frames. My clock always run from 0 to 1.
This is not what I meant. All time is measured in milliseconds in my system,
so the problem is not a matter of units.
The problem is this: Say you have a ball that hits the ground at some point
in time and when that happens you want a sound to be played. In a
clock-based (deterministic) animation you know all from the beginning at
what time the ball hits the ground so you just specify that time value like
this:
// name sound_filename time
sound_point_loop("ball","wavdata/bump.wav",1000*3.5)
This should play the sound after 3.5 seconds. Now, how should this
information be put into the data text file? My sound system include file is
invoked in every frame of the animation, but naturally it should not save
the information "play bump.wav after 3500 milliseconds" every time it is
invoked (which is in every frame). This would create dublicate information.
In my current system such information is simply saved to the file the first
time the system is invoked, that is, in frame 1. The macro is called in all
frames, but only in the first frame does it do something. No problems so
far.
However, in a simulation based system where the ball could be controlled by
some physics system, you don't know from the beginning at what point in time
the ball will hit the ground. So you can't save it to the data file the
first time the system is invoked. You typically don't know it until the
frame that comes right before or right after the impact (assuming the impact
happens between two frames, which is most likely). Then when you invoke the
macro at this point it's no good if it doesn't do anything (because it only
does something in the first frame).
So - I don't quite know how to implement a good solution that works in both
cases.
>> - How should the specification of the data file be? The current one
>> is somewhat a mess.
>
> Not quiet sure what you mean with the data file. The POV-Source?
You haven't seen it. We can discuss it later once I've gotten a few files up
for download.
> Me neither. But if your app just parses the data-file and outputs a
> wave-file, a simple batch-file which runs the app should be
> sufficient.
Yeah. Only, it still requires that you have both Java Virtual Machine and
OpenAL installed - I think.
> I hope some of my comments are of some help. I'd like to have a look
> and all, but I'm currently tied up working on an IRTC entry that
> needs to be finished, but I'll be happy to participate in a few
> brainstorming sessions or discussions, either here or via email. But
> maybe off-topic would be a better area to discuss things then, in
> order not to junk the groups here.
Thanks for the offer.
I don't think it's off-topic, at least not major parts of the discussion.
And it would be impractical if the things we discuss are lost in a few weeks
time. For now I think we can just keep the discussion here.
Rune
--
3D images and anims, include files, tutorials and more:
rune|vision: http://runevision.com
POV-Ray Ring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> // name sound_filename time
> sound_point_loop("ball","wavdata/bump.wav",1000*3.5)
> This should play the sound after 3.5 seconds. Now, how should this
> information be put into the data text file? My sound system include file
is
> invoked in every frame of the animation, but naturally it should not save
> the information "play bump.wav after 3500 milliseconds" every time it is
> invoked (which is in every frame).
SNIP
But the JAVA programm is called after the animation, right? As I understand
it, the pov-source parses and creates a data-file, which the JAVA-app loads
and runs through OpenAL to retrieve a nifty stereo-sound. If that is so,
shouldn't it be easy to just create a macro which, when activated, will
return some data to the data-file? A modified version of the macro above
(perhaps sound_point_once()) would then, add the wave to the data once it is
called. In the ball-hopping example, the macro would only be called directly
after/when it hits a surface. The physics-system would supply the data
needed to pinpoint the moment for the sound to start and call the macro with
that information. It won't get called when there's no hit. Is that a
possibility?
> Yeah. Only, it still requires that you have both Java Virtual Machine and
> OpenAL installed - I think.
Well, that's much like the requirement to install POV-Ray before making use
of the sources, right? Is it bothersome to install OpenAL? A small
readme.txt with guidelines tagged with your app would be all it takes then.
> I don't think it's off-topic, at least not major parts of the discussion.
> And it would be impractical if the things we discuss are lost in a few
weeks
> time. For now I think we can just keep the discussion here.
Well, not off-topic, but if we're rambling some thoughts, we'd use quiet
some space... We'll see. I guess we'll just get banned once we get
off-topic. ;-)
Regards,
Tim
--
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
in news:414b1a41$1@news.povray.org Rune wrote:
> // name sound_filename time
> sound_point_loop("ball","wavdata/bump.wav",1000*3.5)
>
Rune,
Just shooting some stuff that comes up in me.
What was your perception of the process when you started?
I would think of two things, "tracks" and "time-line". Tracks would be
what you call sound_point, think of multi track recording. Every object
has its own track.
The time-line tells us what happens when. In your current macro it seems
that you define start and end time, so you have to know the length of
the whole sequence on beforehand. I'd prefer the data on the time-line
to be independent of the actual length of the sequence, so one does not
have to change values if one does a "10 frame test run".
Track("ship1", position, trigger)
This could be the simplest form of the macro and writes a line like:
- ship1, startframe, endframe, currentframe, position, sound_on/off
From a complete dataset like this, you Java program could figure out
everything needed, like calculating a time-code from the frame data.
Leave out as much information as possible. It gives you maximum
flexibility in case you wan't to change something later on, like gain or
pitch. These are properties of the sound not of the object.
// name sound_filename time
sound_point_loop("ball","wavdata/bump.wav",1000*3.5)
This one could become:
Track("ball", position, trigger)
The Java program should know the relation ball -> bump.wav, not POV-Ray.
The Java script should know the sound-properties of the ball-object,
like should I start the sound one frame, or n milliseconds, before or
after the impact. Should it still have a sound some time after it
bounced, etc. Also you could do some extra calculations in POV-Ray to
determine wether the trigger should switch from off to on.
So you may have to write two scripts, a POV-script and a sound script.
This is more or less what also happens during real filming. Sound and
image are recorded sepparately, have two time-lines and time-codes are
used to match things. When making (multi screen) slide shows it is even
custom to first make the sound track and then match the timing of the
slides to that.
As said, just my thoughts, so don't be bothered too much with them. It's
your project.
Ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Among other things, ingo wrote:
> The Java program should know the relation ball -> bump.wav, not POV-Ray.
> The Java script should know the sound-properties of the ball-object,
> like should I start the sound one frame, or n milliseconds, before or
> after the impact. Should it still have a sound some time after it
> bounced, etc. Also you could do some extra calculations in POV-Ray to
> determine wether the trigger should switch from off to on.
Those are my thoughts too. POV-Ray should be used only to "calculate" the
relative positions of different sound sources and observer, and to get some
other properties (what's the source's speed?) and triggers (did the ball
hit the ground?). Well, maybe the speed can be calculated afterwards too.
By the way, did you (Rune) take into account sound retardation (the time it
takes for the sound to reach the observer)? For this, you'd need the speed
of sound, which I suggest should be an adjustable variable and given in pov
units, this also affects the Doppler effect.
Another thought: the "microphone" doesn't have to be the same as the camera
;-)
--
light_source{9+9*x,1}camera{orthographic look_at(1-y)/4angle 30location
9/4-z*4}light_source{-9*z,1}union{box{.9-z.1+x clipped_by{plane{2+y-4*x
0}}}box{z-y-.1.1+z}box{-.1.1+x}box{.1z-.1}pigment{rgb<.8.2,1>}}//Jellby
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 17 Sep 2004 15:18:28 +0200, "Rune" <run### [at] runevision com>
wrote:
>I've been working on a system to make it possible to easily composite 3D
>sound for POV-Ray animations. By 3D sound I mean sound which is in stereo
>and which also automatically gets louder when the source of the sound gets
>closer to the camera. Dobbler effect is also implemented.
>
Fascinating concept. Good luck with it.
Have you considered simply having povray
render a text file in csound syntax?
csound is a public domain cross-platform
audio rendering package. It's pov-ray for
sound. No need to code any java. :D
I havn't tried this beacause I can't figure
csound out. I do remember that csound will
read in external .wav files so careful use
of variable delays, panning, and volume
(amplitude) envelopes/modulation should
be enough to move sound-sources in 3-space.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
pov### [at] almostbestwebnet wrote:
> Have you considered simply having povray
> render a text file in csound syntax?
> csound is a public domain cross-platform
> audio rendering package. It's pov-ray for
> sound. No need to code any java. :D
>
> I havn't tried this beacause I can't figure
> csound out. I do remember that csound will
> read in external .wav files so careful use
> of variable delays, panning, and volume
> (amplitude) envelopes/modulation should
> be enough to move sound-sources in 3-space.
I did have a look at csound before I found OpenAL, but it didn't look
straightforward or easy to learn. Besides, with csound I'd have to do all
the hard work myself modulating volumes, waves, panning to simulate 3d,
while with OpenAL it really does everything by itself because it's designed
for 3d-environments from the beginning. I don't manipulate any sound data at
all, I just pass on the information that OpenAL needs to do it, like
positions of the sound sources and the camera/listener.
The only problem is that OpenAL is made for real-time and thus plays the
sound immediately. The sound can only be stored in a file by recording what
is being played. My program starts and stops the recording automatically so
that the timing is just right, but there is still some reduction in sound
quality, because of the indirect way it is saved. Not a big deal though.
Rune
--
3D images and anims, include files, tutorials and more:
rune|vision: http://runevision.com
POV-Ray Ring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tim Nikias wrote:
> But the JAVA programm is called after the animation, right? As I
> understand it, the pov-source parses and creates a data-file, which
> the JAVA-app loads and runs through OpenAL to retrieve a nifty
> stereo-sound.
Exactly.
> If that is so, shouldn't it be easy to just create a
> macro which, when activated, will return some data to the data-file?
Yes, it's not a technical problem, it's only a matter of what design is more
clever.
> A modified version of the macro above (perhaps sound_point_once())
Yeah, I'll probably end up with something similar to that...
Rune
--
3D images and anims, include files, tutorials and more:
rune|vision: http://runevision.com
POV-Ray Ring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
ingo wrote:
> What was your perception of the process when you started?
To define points in space from which sound can be emitted and which can be
moved around continuesly.
> I would think of two things, "tracks" and "time-line". Tracks would be
> what you call sound_point, think of multi track recording. Every
> object has its own track.
>
> The time-line tells us what happens when. In your current macro it
> seems that you define start and end time, so you have to know the
> length of the whole sequence on beforehand. I'd prefer the data on
> the time-line to be independent of the actual length of the sequence,
> so one does not have to change values if one does a "10 frame test
> run".
>
> Track("ship1", position, trigger)
What is "trigger" here?
> It gives you maximum
> flexibility in case you wan't to change something later on, like gain
> or pitch. These are properties of the sound not of the object.
Gain and pitch are properties of the object/source, not the sound. This
means that you can play the same sound at several sources at the same time
with different gain/pitch values for each source. If it was a property of
the sound, then you couldn't adjust it on a per-object basis, which would be
a disadvantage. I think this logic makes sense, and it's the logic used by
OpenAL itself anyway. I should mention that one source can only play back
one sound at a time - otherwise per-object gain/pitch would indeed not have
made sense.
>
> // name sound_filename time
> sound_point_loop("ball","wavdata/bump.wav",1000*3.5)
>
> This one could become:
> Track("ball", position, trigger)
How is the time where the sound should be played specified? It's
insufficient to base it on the frame number, as you might want a sound to
start playing at a time value that lies between two frames.
> The Java program should know the relation ball -> bump.wav
I disagree here. All you need to do with my Java program is to specify the
data file to use as input, and then it returns a .wav file. To have to
provide additional input to the Java program would only be more cumbersome
and time-consuming. I like that you can control everything from one place.
, not
> POV-Ray. The Java script should know the sound-properties of the
> ball-object, like should I start the sound one frame, or n
> milliseconds, before or after the impact. Should it still have a
> sound some time after it bounced, etc. Also you could do some extra
> calculations in POV-Ray to determine wether the trigger should switch
> from off to on.
I'm not sure what you mean here, but I also don't see how the Java program
would know all these things.
> So you may have to write two scripts, a POV-script and a sound script.
As it is now, you can have the sound and scene action completely integrated
but you can also have them seperated if you like. I prefer it that way.
Thanks for your thoughts. I hope you can elaborate a bit on the parts I
didn't get.
Rune
--
3D images and anims, include files, tutorials and more:
rune|vision: http://runevision.com
POV-Ray Ring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jellby wrote:
> By the way, did you (Rune) take into account sound retardation (the
> time it takes for the sound to reach the observer)? For this, you'd
> need the speed of sound, which I suggest should be an adjustable
> variable and given in pov units, this also affects the Doppler effect.
This is already the case. In my example code posted in p.b.a you may notice
this line:
sound_set_dobbler_velocity(100)
> Another thought: the "microphone" doesn't have to be the same as the
> camera ;-)
You currently control this with the macro
sound_set_listener(camera_location,camera_forward,camera_up)
...and indeed you can provide it with data which doesn't match that of the
camera.
Rune
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Yes, it's not a technical problem, it's only a matter of what design is
more
> clever.
My LSSM had a similiar problem. Certain Macros add values to the wavefield
and, as you know, those heights then just get smoothened out for a wave-like
effect. What I did was to have the macro add the data only when it is
occuring within the clock_delta of the current frame. That way, even when I
change the scene a little during the rendering (e.g. nudge a few values
while it's already rendering the first frames) it all works out.
Additionally, when stopping the animation and rendering it later on, the
data will get added once it actually pops up, not earlier or later. It
avoids double entry of the data.
--
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
in news:414d4389$1@news.povray.org Rune wrote:
> Thanks for your thoughts. I hope you can elaborate a bit on the parts
> I didn't get.
I'll try, so here's a little demo "scene":
POV-file:
object {
Ship_01
Track("ship_01", position, trigger)
}
object {
Ship_02
Track("ship_01", position, trigger)
}
object {
Ball
Track("ball", position, trigger)
}
Time-line file (output of POV-Ray):
ship_01, frame0, <position_vector>, [...], sound_off
ship_02, frame0, <position_vector>, [...], sound_off
ball , frame0, <position_vector>, [...], sound_off
ship_01, frame1, <position_vector>, [...], sound_on
ship_02, frame1, <position_vector>, [...], sound_off
ball , frame1, <position_vector>, [...], play_sound Contact = -13
ship_01, frame2, <position_vector>, [...], sound_on
ship_02, frame2, <position_vector>, [...], sound_on
ball , frame2, <position_vector>, [...], sound_off
ship_01, frame3, <position_vector>, [...], sound_on
ship_02, frame3, <position_vector>, [...], sound_off
ball , frame3, <position_vector>, [...], sound_off
.....
Sound-file:
track {
ship_01
sound {
engine_noise
gain 10
pitch 2
phase -50
delay 100
}
}
track {
ship_02
sound {
engine_noise
gain 7
pitch 0.5
}
}
track {
ball
sound {
"boinggg.wav"
gain 3
fade_in 5
fade_out 38
delay Contact
}
}
>> Track("ship1", position, trigger)
>
> What is "trigger" here?
A value or string that defines the state of the track. In its simplest
form it could be 'sound_on' or 'sound_off'. Another one could be
"play_sound", that starts a WAV (sound) and plays it to the end. More
complex it could be the letters of the alphabet for speech
syncronisation.
> Gain and pitch are properties of the object/source, not the sound.
Well in the end also the sound is a property of the object ;) just like
a texture.
> This means that you can play the same sound at several sources at the
> same time with different gain/pitch values for each source. If it was
> a property of the sound, then you couldn't adjust it on a per-object
> basis, which would be a disadvantage.
By using a sepparate sound render file there is no such disadvantage.
The advantage is, or may be, that you don't have to render the images
again if you want to change the properties of a sound linked to an
object.
Now if POV-Ray had inbuild sound capacities it would be more logic to
add all the sound properties to the object inside SDL just like
textures. But the sound creation proces is completely sepparated, then
to me it is logical to also sepparate the script. This also means that
if the system is general enough, and with less extra work, the user
could use a different language binding to OpenAL or even a completely
different sound rendering systems.
Maybe the time-line file created by POV-Ray can also be used for
completely different things.
>> // name sound_filename time
>> sound_point_loop("ball","wavdata/bump.wav",1000*3.5)
>>
>> This one could become:
>> Track("ball", position, trigger)
>
> How is the time where the sound should be played specified? It's
> insufficient to base it on the frame number, as you might want a
> sound to start playing at a time value that lies between two frames.
You can have POV-Ray calculate the exact moment of contact and then pass
that information to the sound rendering system. In the demoscene the
first frame beyond the moment of contact sets the trigger for the sound
to play and defines a variable for the delay.
>> POV-Ray. The Java script should know the sound-properties of the
>> ball-object, like should I start the sound one frame, or n
>> milliseconds, before or after the impact. [...]
>
> I'm not sure what you mean here, but I also don't see how the Java
> program would know all these things.
You're right the JAVA program can't do much without the proper
information. This information has to be in the Time-line file, generated
by POV-Ray and, if you want to sepparate sound and image generation
files, in the Sound-file.
Ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
in news:414ae431@news.povray.org Rune wrote:
> - How can I make the java program more clean and well-structured? How
> does one write a text parser? (The current one is a hack.)
>
You could use an existing parser, like CSVParser
http://ostermiller.org/utils/CSV.html and have POV-Ray write comma
sepparated values. Or use XML, or maybe there is a JAVA based (windows)
ini-file parser.
Ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
ingo wrote:
> in news:414d4389$1@news.povray.org Rune wrote:
>
>> Thanks for your thoughts. I hope you can elaborate a bit on the parts
>> I didn't get.
>
> I'll try, so here's a little demo "scene":
I don't get the logic behind your described system. There seems to be only
one sound attached to each source. A source can play many different sounds,
just not at the same time. How would one specify that in your system? Also,
when pitch and gain are described seperately from the scene file, it seems
difficult to change pitch and gain dependent on variables in the scene.
Pitch and gain can change over time just like position, and it should be
just as simple to do this. I also don't get your conceot of sound_on and
sound_off. You tell your ball object to play a sound while it is off at the
same time, or at least right in the next frame?
I have changed my own system. The code below is working code:
// START POVSOUND
sound_start("soundtest.txt")
sound_set_milliseconds_per_clock(1000,0) // second value is offset
#declare Time = sound_get_time();
#declare EngineSound = "../wavdata/engine.wav";
#declare HoverSound = "../wavdata/hovercraft.wav";
sound_set_gain_once(1000*0, 0.5)
sound_set_dobbler_factor_once(1000*0, 1.0)
sound_set_dobbler_velocity_once(1000*0, 100)
sound_set_listener(Time,camera_location,camera_forward,camera_up)
#declare ship1_starttime = 1000*0;
#declare ship1_endtime = 1000*10;
sound_point_create_once(ship1_starttime,"ship1")
sound_point_destroy_once(ship1_endtime,"ship1")
sound_point_loop_once(1000*0,"ship1",EngineSound)
#if ( is_between(Time,ship1_starttime,ship1_endtime) )
sound_point_location(Time,"ship1",ship1_translate)
sound_point_gain(Time,"ship1",2.0) // can easily be changed over time
sound_point_pitch(Time,"ship1",1.0) // if you use a variable instead of a
number
#end
#declare ship2_starttime = 1000*0;
#declare ship2_endtime = 1000*10;
sound_point_create_once(ship2_starttime,"ship2")
sound_point_destroy_once(ship2_endtime,"ship2")
sound_point_loop_once(1000*0,"ship2",HoverSound)
#if ( is_between(Time,ship2_starttime,ship2_endtime) )
sound_point_location(Time,"ship2",ship2_translate)
sound_point_gain(Time,"ship2",1.0)
sound_point_pitch(Time,"ship2",1.0)
#end
sound_end()
// END POVSOUND
> A value or string that defines the state of the track. In its simplest
> form it could be 'sound_on' or 'sound_off'. Another one could be
> "play_sound", that starts a WAV (sound) and plays it to the end. More
> complex it could be the letters of the alphabet for speech
> syncronisation.
So it is up to the user to figure out how to provide the right trigger
string for every frame? Sounds like it would require lots and lots of
#if(...) #declare trigger = ... #end -structures...
>> Gain and pitch are properties of the object/source, not the sound.
>
> Well in the end also the sound is a property of the object ;) just
> like a texture.
Yes indeed - but that doesn't mean that gain and pitch are properties of the
sound.
>> This means that you can play the same sound at several sources at the
>> same time with different gain/pitch values for each source. If it was
>> a property of the sound, then you couldn't adjust it on a per-object
>> basis, which would be a disadvantage.
>
> By using a sepparate sound render file there is no such disadvantage.
> The advantage is, or may be, that you don't have to render the images
> again if you want to change the properties of a sound linked to an
> object.
Pitch and gain can also be dependent on how the object moves around and be
set for every frame. It would not be easy to manually edit them if they're
specified for each frame. Besides, you don't have to render the images
again. You can just render with "+w1 +h1 -f". It has worked fine for me.
> This also means that
> if the system is general enough, and with less extra work, the user
> could use a different language binding to OpenAL or even a completely
> different sound rendering systems.
Seeing as there are no sound rendering alternatives available yet, his is
not really a priority.
> Maybe the time-line file created by POV-Ray can also be used for
> completely different things.
>
>>> // name sound_filename time
>>> sound_point_loop("ball","wavdata/bump.wav",1000*3.5)
>>>
>>> This one could become:
>>> Track("ball", position, trigger)
>>
>> How is the time where the sound should be played specified? It's
>> insufficient to base it on the frame number, as you might want a
>> sound to start playing at a time value that lies between two frames.
>
> You can have POV-Ray calculate the exact moment of contact and then
> pass that information to the sound rendering system. In the demoscene
> the first frame beyond the moment of contact sets the trigger for the
> sound to play and defines a variable for the delay.
It still sounds like the user have to put a lot of effort into creating the
right triggers...
> You're right the JAVA program can't do much without the proper
> information. This information has to be in the Time-line file,
> generated by POV-Ray and, if you want to sepparate sound and image
> generation files, in the Sound-file.
But how is the time-line file generated? It sounds like you say that it
should be edited manually, even though it contains data for every frame and
thus has a huge amount of data.
Your time-line file sounds very similar to the data format that my system
outputs and which my Java program reads. But the whole point of my macros is
that the user shouldn't have to edit that file manually.
This is what the data-file looks like (the first number on each line is the
time in milliseconds):
0 system gain 0.5
0 system dobbler_factor 1
0 system dobbler_velocity 100
0 system listener <0,0.3,1.2> <0,0,1> <0,1,0>
0 source ship1 create
0 source ship1 loop ../wavdata/engine.wav
0 source ship1 position <0,0,1>
0 source ship1 gain 2
0 source ship1 pitch 1
0 source ship2 create
0 source ship2 loop ../wavdata/hovercraft.wav
0 source ship2 position <1,0.6,10>
0 source ship2 gain 1
0 source ship2 pitch 1
33 system listener <0,0.3,1.18333> <0.00333333,0,1> <0,1,0>
33 source ship1 position <0.418757,0,1>
33 source ship1 gain 2
33 source ship1 pitch 1
33 source ship2 position <1,0.6,9.99123>
33 source ship2 gain 1
33 source ship2 pitch 1
66 system listener <0,0.3,1.16667> <0.00666667,0,1> <0,1,0>
66 source ship1 position <0.836778,0,1>
66 source ship1 gain 2
66 source ship1 pitch 1
66 source ship2 position <1,0.6,9.96493>
66 source ship2 gain 1
66 source ship2 pitch 1
Rune
--
3D images and anims, include files, tutorials and more:
rune|vision: http://runevision.com
POV-Ray Ring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tim Nikias wrote:
> What I did was to have the macro add the data only when
> it is occuring within the clock_delta of the current frame.
That's a good idea. I have implemented two versions of every macro now - one
that writes the data to the file whenever the macro is called, and one which
only does it if the time of occurance is within the clock_delta (backwards)
of the current frame.
Rune
--
3D images and anims, include files, tutorials and more:
rune|vision: http://runevision.com
POV-Ray Ring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
in news:414dac97$1@news.povray.org Rune wrote:
> I don't get the logic behind your described system. There seems to be
> only one sound attached to each source.
One can add as many sounds as one wants by adding more track macros to
the object or by adding more sounds to the sound file and use just one
track macro. As said, it just an idea not a comletely developed system.
What is important i.m.o is the sepparation of sound and image aspects,
POV-Ray outputs all kinds of spatial data, the soundfile gives the sound
data and the Java program combines it to a sound-track.
> Also, when pitch and gain are described
> seperately from the scene file, it seems difficult to change pitch
> and gain dependent on variables in the scene.
Ah, I interpreted your gain wrong and thought of it as an offset value,
...
> Pitch and gain can change over time just like position, and it should
> be just as simple to do this.
... the Java program calculates the actual gain and pitch as a result of
the speed, and proximity of the object to the camera.
> I also don't get your conceot of sound_on and sound_off.
> You tell your ball object to play a sound while it is off at the same
> time, or at least right in the next frame?
One thing I realy miss in POV-Ray's macros is that it is not possible to
specify default argument values (see for example
http://www.python.org/doc/2.3.4/tut/node6.html#SECTION006710000000000000
000 )
So has a double meaning, there is no sound or turn the current sound,
started with sound_on, off. But that is limiting, the sound of the ball
is longer than the duration of the contact. So its sound is started with
play_sound. The sound takes as long as the duration of the WAV or maybe
the duration could be set in the sound file.
> So it is up to the user to figure out how to provide the right
> trigger string for every frame? Sounds like it would require lots and
> lots of #if(...) #declare trigger = ... #end -structures...
Yes, in the end its always the user that has to figure out when to
trigger a sound. In one of your examples:
"sound_point_loop("ball","wavdata/bump.wav",1000*3.5)"
the user also has to figure out when to start the sound. The difference
is that when you change something in your animation, you also have to
recalculate the timing and change it in the file. If you can use event
based triggers, using #if or #case, you only have to set it up once.
Actually you don't even need to know the length of the animation in
advance, it can all be calculated afterwards.
In case you want to add sound to each object in your particle system,
would you want to figure out the timing for each particle or once set up
a (general) event based system.
> You can just render with "+w1 +h1 -f". It has worked fine for me.
Yes.
> But how is the time-line file generated? It sounds like you say that
> it should be edited manually, even though it contains data for every
> frame and thus has a huge amount of data.
There's no manual editing of POV-Ray output. POV-Ray provides frame
number, spatial data, maybe even speeds and accelerations, whatever you
want. Everything is written to file, per object / track, per frame.
Frome these data, the total numer of frames and the framerate, plus the
data from the sound-file the Java program can create a timeline per
object or one for the whole animation. Internaly that can indeed be
something simmilar to your data-file.
> [...]
> 0 source ship1 create
> 0 source ship1 loop ../wavdata/engine.wav
> 0 source ship1 position <0,0,1>
> 0 source ship1 gain 2
> [...]
Ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
ingo wrote:
>> Pitch and gain can change over time just like position, and it should
>> be just as simple to do this.
>
> ... the Java program calculates the actual gain and pitch as a result
> of the speed, and proximity of the object to the camera.
...but there can be lots of other reasons to change gain and pitch than just
to simulate distance and doppler effect. For example I want my hovercraft to
rise from the ground and into the air, and while doing this the sound of the
engine rises both in volume (=gain) and in pitch. I can easily control this
from within my POV-Ray file. What's left for the sound-file you propose?
Just to specify the path/filename of each sound? It seems a little silly to
have a seperate file just for that.
> In case you want to add sound to each object in your particle system,
> would you want to figure out the timing for each particle or once set
> up a (general) event based system.
My current approach works fine as an event-based system. For example, if you
want to play a sound every time a particle hits an object, you can just call
a macro every time it happens:
// time source sound
sound_point_play(impact_time, concat("",particle_id), BoingSound)
> There's no manual editing of POV-Ray output.
So the time-line should be generated by the .pov-file after all? And only
the sound-file should be seperated from it? But then again, with a seperate
sound-file you can not as easily control gain and pitch over time, as I
mentioned... So I still think it's most logical to have it all created from
the .pov-file.
Rune
--
3D images and anims, include files, tutorials and more:
rune|vision: http://runevision.com
POV-Ray Ring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rune wrote:
> // time source sound
> sound_point_play(impact_time, concat("",particle_id), BoingSound)
Oops, I mean str(particle_id,0,0) instead of concat("",particle_id) ;)
Rune
--
3D images and anims, include files, tutorials and more:
rune|vision: http://runevision.com
POV-Ray Ring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
in news:414e0d46@news.povray.org Rune wrote:
> ...but there can be lots of other reasons to change gain and pitch
> than just to simulate distance and doppler effect. For example I want
> my hovercraft to rise from the ground and into the air, and while
> doing this the sound of the engine rises both in volume (=gain) and
> in pitch. I can easily control this from within my POV-Ray file.
That's a dissapointment, OpenAL only knows about location and velocity,
not acceleration. Hmmm, so for other effects one has to come up with one's
own way to control pitch/gain.
> What's left for the sound-file you propose?
Sounds, source attributes, listener attributes, maybe buffer attributes,
everything except spatial data, triggers (state) and the frame stuff.
Ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
ingo wrote:
>> What's left for the sound-file you propose?
>
> Sounds, source attributes, listener attributes, maybe buffer
> attributes, everything except spatial data, triggers (state) and the
> frame stuff.
I'm not sure what attributes you mean. With pitch and gain categorized as
"frame stuff" there really is not much left. OpenAL is pretty simple. It
automatically controls doppler effect and distance-related loudness, but
besides that one have to specify things manually. It also doesn't handle
phase, delay, fade-in or fade-out or other effects.
Still, having access to OpenAL's sound rendering is superior to what has
been available to POV-Ray animators before and creative minds can do a lot
with it.
It may sound like I've only been objecting to suggestions and ideas in this
discussion, but the truth is that I've leaned a lot from the discussion and
I've also changed some aspects of the design of the system based on the
things we've discussed.
So thanks for all the feedback, Ingo, Tim and others!
I'm working on a better demo scene now while improving the system slightly
at the same time, and after that I'll release the first version.
Rune
--
3D images and anims, include files, tutorials and more:
rune|vision: http://runevision.com
POV-Ray Ring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> So thanks for all the feedback, Ingo, Tim and others!
No problem, always a pleasure participating in these groups. :-)
> I'm working on a better demo scene now while improving the system slightly
> at the same time, and after that I'll release the first version.
Great, looking forward to testing it! This time, we won't have to switch
speakers, right? :-P
Regards,
Tim
--
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
in news:415035eb$1@news.povray.org Rune wrote:
> I'm not sure what attributes you mean.
Well indeed there isn't much in OpenAL to specify, the only one left would
be directionality.
> It may sound like I've only been objecting to suggestions and ideas
> in this discussion,
Don't worry about that :) I've stoped trying to convince people in
discussions many years ago, I only see it as an excange of idea's.
> I'm working on a better demo scene now {...]
Looking forward to it.
Ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
ingo wrote:
> Well indeed there isn't much in OpenAL to specify, the only one left
> would be directionality.
Yes, which I'd also prefer could be changed from frame to frame... ;)
But in order to be able to release the initial version of the system faster,
directionality won't be supported in the first version - or rather the
0.0001'th version.
Rune
--
3D images and anims, include files, tutorials and more:
rune|vision: http://runevision.com
POV-Ray Ring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tim Nikias wrote:
> Great, looking forward to testing it! This time, we won't have to
> switch speakers, right? :-P
Nope, that one's fixed. :)
Rune
--
3D images and anims, include files, tutorials and more:
rune|vision: http://runevision.com
POV-Ray Ring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I'm having major problems getting anywhere with the sound system. This is
caused by a bug in OpenAL or JOAL.
Basically, since OpenAL operates with a limited amount of simultaneous
sources - and it's quite few - I have to be able to dynamically create and
delete sources so that they're only used when needed. However, when I try to
dynamically do that, Java crashes...
For anyone interested I posted a thread about it in this forum:
http://www.javagaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=JOAL;action=display;num=1096154724
Not sure what to do now... :(
Rune
--
3D images and anims, include files, tutorials and more:
rune|vision: http://runevision.com
POV-Ray Ring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I've just had a very rough, first look at it. I'm no expert in Java, much
less OpenAL and JOAL (never used latter two), but it might be some issue
with the arrays which isn't liked. E.g. arrays are initialized with a
certain amount of indices, and the problem might be that when you try to
remove a source, JOAL/OpenAL tries to remove an index. But that's highly
guess work.
Have you tried using linked lists instead of arrays? Or maybe just a few
objects for starters, to check if it'll work at all?
--
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tim Nikias wrote:
> E.g. arrays are initialized with a certain amount of indices,
> and the problem might be that when you try to remove a source,
> JOAL/OpenAL tries to remove an index. But that's highly guess work.
>
> Have you tried using linked lists instead of arrays? Or maybe just a
> few objects for starters, to check if it'll work at all?
In one of my tests I'm using neither arrays nor lists, just two variables to
store the ID's for the two sources. Well, each source requires an integer
array as one of the parameters, but I use one 1-element array for each of
the two sources. These arrays can't be replaced with linked lists, since
it's something internal in JOAL that I have no control over.
Rune
--
3D images and anims, include files, tutorials and more:
rune|vision: http://runevision.com
POV-Ray Ring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rune <run### [at] runevisioncom> wrote:
> delete sources so that they're only used when needed. However, when I try to
> dynamically do that, Java crashes...
If it is really java itself that crashes, then this is a bug in java, not
necessarily in the application.
Have you tried upgrading to a newer version of java?
Lutz-Peter
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> In one of my tests I'm using neither arrays nor lists, just two variables
to
> store the ID's for the two sources. Well, each source requires an integer
> array as one of the parameters, but I use one 1-element array for each of
> the two sources. These arrays can't be replaced with linked lists, since
> it's something internal in JOAL that I have no control over.
Hm. Would it be possible to delete the sources and then just recreate the
ones you still need? Or does that result in an audible sound-effect?
I'm not sure how OpenAL etc works, so just a question: if the source is
created, is it still possible to just mute it? Maybe you could bypass the
entire problem by simply letting the User define "tracks", and your
application won't output a single sound-file, but rather several ones: one
per track. Might be useful for mixing/post-processing purposes anyway, so it
wouldn't be a waste even if there is a better solution than working around
it.
--
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Lutz-Peter Hooge wrote:
> Rune <run### [at] runevisioncom> wrote:
>
>> delete sources so that they're only used when needed.
>> However, when I try to dynamically do that, Java crashes...
>
> If it is really java itself that crashes
It is...
> then this is a bug in java, not necessarily in the application.
> Have you tried upgrading to a newer version of java?
I have 1.4.2_05, which appears to be the newest version.
I'm currently trying out the competing Java binding for OpenAL that is
included with LWJGL (Light-Weight Java Game Library) and it doesn't make
Java crash where JOAL does, but it does make Java crash on some other
occasions. Besides that, the two implementations give rather different
results for the same input. I'm getting seriously confused and annoyed by
the whole thing... :(
Rune
--
3D images and anims, include files, tutorials and more:
rune|vision: http://runevision.com
POV-Ray Ring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tim Nikias wrote:
> Hm. Would it be possible to delete the sources and then just recreate
> the ones you still need? Or does that result in an audible
> sound-effect?
I'm pretty sure it would, besides being a nigtmare to program.
> I'm not sure how OpenAL etc works, so just a question: if the source
> is created, is it still possible to just mute it?
Yes. But the problem is the limited amount of sources.
> Maybe you could bypass the entire problem by simply letting the User
define "tracks",
> and your application won't output a single sound-file, but rather
> several ones: one per track. Might be useful for
> mixing/post-processing purposes anyway, so it wouldn't be a waste
> even if there is a better solution than working around it.
I don't like it very much, but it may be a last resort...
Rune
--
3D images and anims, include files, tutorials and more:
rune|vision: http://runevision.com
POV-Ray Ring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rune <run### [at] runevisioncom> wrote:
> I have 1.4.2_05, which appears to be the newest version.
Ok. There is also java 1.5, but its still a release candidate.
> I'm currently trying out the competing Java binding for OpenAL that is
> included with LWJGL (Light-Weight Java Game Library)
Oh, so I assume OpenAL is not native java, but rather some library written
in C++ or something? Then maybe I was wrong and it could crash java without
an actual bug in java itself.
Lutz-Peter
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Lutz-Peter Hooge wrote:
> Oh, so I assume OpenAL is not native java, but rather some library
> written in C++ or something? Then maybe I was wrong and it could
> crash java without an actual bug in java itself.
Yes indeed, that's the case. This is the error message:
An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005) occurred at
PC=0x2CD9D94
Function=alDistanceModel+0x1814
Library=D:\WINDOWS\System32\OpenAL32.dll
Rune
--
3D images and anims, include files, tutorials and more:
rune|vision: http://runevision.com
POV-Ray Ring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Could you render each sound independently, then mix the tracks down after
everything's done?
--
KC6ETE Dave's Engineering Page, www.dvanhorn.org
Microcontroller Consultant, specializing in Atmel AVR
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Dave VanHorn wrote:
> Could you render each sound independently, then mix
> the tracks down after everything's done?
I don't like that option. If you have a 30 seconds animation with 20 sounds,
it'll take 10 minutes just to generate the sound. This is because the sound
rendering engine works in real-time, so it it has to render each sound
seperately, which means one sound after the other (as well as all the
silence before and after the sound, in order to get the timing right).
However, right now I'm looking at another Java implementation of OpenAL
implemented in LWJGL ( http://www.lwjgl.org ) which doesn't have the
multiple-sound problem. I'm having some different problems with it though...
Rune
--
3D images and anims, include files, tutorials and more:
rune|vision: http://runevision.com
POV-Ray Ring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
in news:41588eec@news.povray.org Rune wrote:
> I'm having some different problems with it though...
>
>
Can't help with your problems, but maybe this is an alternative sound
system:
http://www.muse.demon.co.uk/vspace/vspace.html
You won't need Java as it uses its own, a bit SDL like, scripting
language.
Ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
ingo wrote:
> Can't help with your problems, but maybe this is an alternative sound
> system:
>
> http://www.muse.demon.co.uk/vspace/vspace.html
>
> You won't need Java as it uses its own, a bit SDL like, scripting
> language.
Thanks for pointing me to this. It looks interesting, but as far as I can
see, it doesn't have support for looping sounds, nor for setting the pitch
of a sound. Those two things I find rather important... I think I'll stick
with OpenAL. I just need some time getting it to work properly...
Rune
--
3D images and anims, include files, tutorials and more:
rune|vision: http://runevision.com
POV-Ray Ring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
