[IPAndrews]

Hi,

I'm using calls to add-background-bitmap to ... erm... add background bitmaps... to my mission. I'm doing this completely at random by passing rand-multiple 0 179 as the first parameter, 0 359 as the second and third parameters. Problem is the placement does not seem entirely random. Most of the bitmaps end up getting piled on one spot whilst much space always ends up empty of bitmaps.

Can anyone explain this behaviour? More importantly does anyone know how I can work around it?

[CP5670]

I guess it sort of makes sense. The pitch/heading coordinate pairs are closesly concentrated around the points where the heading is 90 or 270, so the probability of getting a point in one of those areas there is higher than anywhere else. (if the heading falls between, say, 70 and 110 or 250 and 290, then the value of the pitch has little effect and you always get a nebula bitmap in one of those areas). I guess the natural way to get around this is to just add in some kind of a weight function so that the probability of choosing a point diminishes as its heading approaches 90 or 270.

Although adding these things at random doesn't work very well anyway IMO; you just end up with a lot of small splotches around the skybox instead of any coherent pattern.

[StratComm]

You aren't using the background-changing SEXPs to actually place your mission background, are you?  That's totally the wrong way to go about it.  You should be using the background editor and placing them manually.  You'll get better patterns and more coherent locations for everything.  I'm also somewhat curious as to how you get a sun in there with this method.

[Trivial Psychic]

What IPAndrews is trying to do is for his BHX project which has a series of missions that get repeated in a random pattern.  He wants to have the backgrounds to be alterable so that the mission area appears different as far as the game area is concerned.  You can't do that with the background editor.

[phreak]

The background bitmap parameters are sort of funky.  I can't really describe it, but place a bitmap with a pitch of 60 and a heading of zero.  Start moving the heading over toward 90 and you can see that the bitmap follows a path downwards until it meets the xy plate when the pitch is 90.  I think whats going on is that the background follows a circle that is centered upon the origin and rotated about the line x=0 by however many degrees "pitch" is.

to demonstrate, hold a coaster with two fingers on one hand pinching the center of the coaster.  Push down on the rim of the coaster and it'll pivot up and down.  the background bitmap will be following the edge of it.

all 3 orientation parameters of add-background-bitmap should also be covering [0..359]

[IPAndrews]

If we assume that when you create a new blank mission and face "forward" (ie: the place where a bitmap at 0,0,0 would appear) then as far as I understand it:

The top number is the degree rotation around the x axis.
The bottom number is the degree rotation around the y axis.
I think the bottom rotation is applied before the top rotation.

I do not think the middle number has any effect on position itself and just affects the rotation of the bitmap in whatever position the other two numbers put it in. If I've figured all that correctly then surely a top number of 0-180 and a bottom number of 0-360 would cover every possible position in the sky sphere. If I'm wrong please tell me! That might be my problem. Could it be the rand-multiple sexp just, isn't that random?

[IPAndrews]

to demonstrate, hold a coaster with two fingers on one hand pinching the center of the coaster.  Push down on the rim of the coaster and it'll pivot up and down.  the background bitmap will be following the edge of it. all 3 orientation parameters of add-background-bitmap should also be covering [0..359]

If the top number represents the tilt of the coaster and the bottom number represents the position on the rim of the coaster then surely the top number only needs to go from 0-180 (coaster facing upwards through to upside down) since the rim then reaches all possible positions in the sphere?

By the by. I'm using "top number, bottom number" etc... here to refer to FRED because the actual names Pitch, Bank, and Heading do not seem veryaccurate or meaningful to me. Again though that could just be me 

[SadisticSid]

I find it helps to think of a minigun on a rotating turret.

Pitch = how far up or down in the air the barrels are pointing - what it's aiming at on the vertical plane.
Bank = how far the barrels have rotated around from their starting positions when firing.
Heading = how far the turret base has rotated - what it's aiming at on the horizontal plane.

[Mefustae]

It would be a lot easier if they showed up when you were in FRED, ala the Suns...

[StratComm]

What IPAndrews is trying to do is for his BHX project which has a series of missions that get repeated in a random pattern.  He wants to have the backgrounds to be alterable so that the mission area appears different as far as the game area is concerned.  You can't do that with the background editor.

So the thing to do would be to build 5-6 backgrounds, take all of their values, and have a random number SEXP determine which set you chose to load.  Beats the hell out of random placement, but also lets you randomize the mission environment somewhat.

It would be a lot easier if they showed up when you were in FRED, ala the Suns...

They do for me.  You are using FRED in HTL mode, right?

[IPAndrews]

So the thing to do would be to build 5-6 backgrounds, take all of their values, and have a random number SEXP determine which set you chose to load.  Beats the hell out of random placement, but also lets you randomize the mission environment somewhat.

That's going to take a huge number of sexps and even then you're only going to have a handful of backgrounds. They have to be convincing as backdrops for 30 missions involving any 2 of 10 warring factions? Ain't working for me. I did think of using sky spheres and the skysphere swap sexp but to be honest it'd mean creating a large number of skyboxes (say 10 per race of 10, that's 100!) and I wouldn't know where to start creating one never mind 100.

[Mefustae]

They do for me.  You are using FRED in HTL mode, right?[

Uh... sure... but if I had to tell someone about this who had no idea what you were on about, what would I tell this supposed person?

[karajorma]

Create a shortcut for FRED, rightmouse it click properties and change the target to fred2_open_r.exe -fredhtl -jpgtga -spec -glow

You did actually reply to a thread where I told someone else how to do it

[Mefustae]

... 

Great. Still no nebulas in-Fred. But we did succeed in slowing my computer down by a factor of 10, so that's a benchmark we can aim to surpass. Now, let's approach my problem as a team, namely one that doesn't include me. Go team!

[StratComm]

That's going to take a huge number of sexps and even then you're only going to have a handful of backgrounds. They have to be convincing as backdrops for 30 missions involving any 2 of 10 warring factions? Ain't working for me. I did think of using sky spheres and the skysphere swap sexp but to be honest it'd mean creating a large number of skyboxes (say 10 per race of 10, that's 100!) and I wouldn't know where to start creating one never mind 100.

Admittedly true, but the quality of a random backdrop is generally so poor that only having a couple of options available is better than that.  The skybox method would be preferable really, but as you say that's a lot of skyboxes to make.  I'd rather have a single background set per race and apply it to all of said race's missions than rely on the random generator for anything approaching sane placement.

But that's just me.  There are a thousand different ways to approach the problem, and everyone must chose their own I guess.

[IPAndrews]

There are a thousand different ways to approach the problem, and everyone must chose their own I guess.

And they're all a ludicrous amount of work, and/or rubbish

[IPAndrews]

Okay dudes. I've finished this code, and figured away around the nebulae piling problem (each new neb is placed at an offset from the previous one). The results can be seen below.



Anybody want me to upload the code?

[starfox]

By all means, IMO 
That looks fantastic...

[Mefustae]

My question remains, however; how the smeg do you get the Nebulae to show up in FRED_Open 3.6.5, if at all?

[IPAndrews]

My question remains, however; how the smeg do you get the Nebulae to show up in FRED_Open 3.6.5, if at all?

The mission doesn't have any backgrounds set in FRED. There's no need to.