Guild of Writers

I made two nested sound regions, one region for grass footsteps (large) and inside the woodbridge footsteps, see picture;



and the text properties look like this;
(for the grass region there is ofcource 'grass' in the surface field)


As written on the picture, you can only hear the woodbridge sound between the yellow lines, on the rest of the bridge you hear the grass sound.
Is this because the bridge is 'bend' or is there something that I am doing wrong? Please any advise.

Regards,
Frits

I think figured it out, I had the region rotated in topview. For some reason it will not work correctly when a region is rotated. After I aligned it with X an Y it works perfectly.
Is this a known problem or did I stumble on something new?

Regards,
Frits

Realy, has no one any command on this issue?

Regards,
Frits

I don't know, it might actually have something to do with actual overlapping sound regions.

Though I did have a similar experience in my shell, turned out that the region I had made didn't have faces on every side of the mesh even though I got a nice pink box, and all the vertices were there.

in the end I switched the draw type of the region to solid, and selected 4 vertices of a face and pressed the "F" key for every face that may or may not was there.
The other thing I did differently to you is I declared the sound regions in AlcScript only the 2 logic properties I used were
string: type value: region
string: page_num value: 119

for you the best option would be possibly be having 2 sound regions on either side of the bridge, as that is the normal approach to these things unless of course the 2 regions are of different types, eg a ladder region and a sound region

There is also the issue of the pyPRP exporter not taking Object transformations into account when exporting the geometry. I.e. if you have scaled and rotated the region in object mode, you may have to "Apply" those transformations from the Object data to the Mesh (ctrl-A in object mode) - it does sound like you (as far as the exporter was concerned) had that long box in reality lying across the bridge, rather than along it.
Easiest way to avoid having to deal with ths stuff, is probably to do all manipulations in edit mode. :7

That is not always true. For sprites, sittingmods and objects with a facing conditional all rotations must be left intact. Applying transformations to those objects breaks them. I always rotate such objects in object mode and they are exported fine.

Grogyan wrote:I don't know, it might actually have something to do with actual overlapping sound regions.

The sound regions are not overlapping, this sound region is completely inside the other (verry big) sound region.

Jojon and D'Lanor; I have not a clue what you are talking about, I am just a beginner with Blender.

This picture belongs to my first post (topview), here you can only hear the woodbridge sound in the middle part of the bridge. For some reason it will not export right.



Now I have changed the rotation of the region back to normal,



and the sound workes perfect. Still wondering why I can't rotate this sound region?

Regards,
Frits

Frits wrote:

Grogyan wrote:Still wondering why I can't rotate this sound region?

First of all: amazing looking work for an absolute beginner, although I gather you have experience with other modelling packages.

While I don't know whether this actually has anything to do with your problem, here's how it more-or-less works:

First, the term "object" is not interchangeable with "mesh".

Structurally-wise, you can think of the object as a sort of container, into which you can put stuff, be it a mesh, a lamp, a spline mesh or single curve(s), a mathematical primitive, or whatever.

The object has its own coordinate system, which can be translated (moved, or rather positioned) and transformed (rotated, scaled, sheared, etc), within the main "Scene" coordinate system and everything that you put in the object, is subject to these manipulations. That is; if you have a 1x1x1 cube mesh inside the "object" container (the proper Blender term is that the object is "parent" to the mesh) and scale the object to twice its size, the cube will blow up on screen, but the mesh data, still says it's a 1x1x1 cube, not 2x2x2. It remains a 1x1x1 cube, but the coordinate system it is drawn within, is twice the size of the scene one.
The same applies to rotation; if you rotate your cube object 45 degrees, you see the cube turning on screen - however what you have turned, is not the actual vertices of the mesh, but the entire coodinate system that they are positioned within - you have turned the container and the stuff that is in it, turns with it.

The problem arises when we use pyPRP to export an age, because with the exception of some things that specifically requires to know what is front and back, up and down on an object (..and I don't know whether there is any particular reason for this inconsistency), pyPRP doesn't necessarily look at which way the container is pointed, or how big it is and adjust the mesh data accordingly - it takes the mesh vertex coordinates and put them as-is in the coordinate system for the entire age, giving you what you would have had if the container (object) had not been scaled or rotated at all.

Therefore, you may need to "apply" any changes that you have made to the Object, to the Mesh. This will reset the object to scale=1, rotation=0, etc. and alter the actual mesh, so that it looks as it did before the application - it will have coordinates that are "compatible" with the scene coordinate system.

Select the little hand icon in your view toolbar. This will make the incredibly useful "3D Transform widget" show up on screen. Notice how its arrows point the same way as the equivalent arrows for the scene coordinate system, down in the corner of the view window? Now change the widget's orientation from "Global" to "Local" (selector button near the hand icon) -- now you can see which way the Object's coordinate system is facing. Notice how these arrows turn with the cube, when you rotate it. It is actually the other way around; the cube turns with them; they are the X, Y and Z axi that the mesh data is fitted into -- then, they in turn are fitted into the larger encompassing scene coordinate system.
The remaining three icons in the button cluster, decides whether you currently use the widget to move, scale or rotate the selected object(s)/vert(s) and the selector to the left of that cluster, decide where the widget is draw in the view, although primarily it is the "pivot point" around which rotation and scaling takes place - could be the currently selected vertex, or if you have more than one selected, you could have it placed at their median point, or at the cursor - whatever suits you.

Hope this helped...

Frits wrote:Jojon and D'Lanor; I have not a clue what you are talking about, I am just a beginner with Blender.

If you have not used the special object types I mentioned you don't have to worry about them and you can follow Jojon's excellent instructions. I just wanted to point out that there are exceptions.

Jojon wrote:The problem arises when we use pyPRP to export an age, because with the exception of some things that specifically requires to know what is front and back, up and down on an object (..and I don't know whether there is any particular reason for this inconsistency), pyPRP doesn't necessarily look at which way the container is pointed, or how big it is and adjust the mesh data accordingly - it takes the mesh vertex coordinates and put them as-is in the coordinate system for the entire age, giving you what you would have had if the container (object) had not been scaled or rotated at all.

Basically, Uru supports both objects with and without object Coordinates/Rotation/Scaling. Only objects that have this "Coordinate Interface" that stores the Object Coordinates, can be moved, rotated or scaled in real time (with Python or Animations). The others are absolutely static, and can only be enabled or disabled.

PyPRP let's you distinguish between these objects, by use of the "Actor" button in Blenders "Logic Properties" Panel.
If an object is an Actor, it's Coordinates/Rotation/Scale will be transferred to Uru (And the object will be movable/rotatable/scalable), and if it is not, then PyPRP applies the object's Coordinates/Rotation/Scale to the mesh data before exporting it to Uru. The object's base coordinates will always be 0,0,0 for those objects.

As you probably understand, objects that are supposed to be moved, like kickables, or dynamic objects, need to have their base coordinates in Uru.
Also, objects that specify a location, like Sound Emitters, Animation SeekPoints, or other actions that define a source point or destination point, you'll need to make your object an Actor.

P.S.
Frits, if you don't understand this, don't worry, it's not an answer for your problem or anything, if you do understand it that's nice though.