19 replies to this topic

[Shoopity]

TL:DR version: I figured out how to make a Flasher object always face the player, as well as take into account the the size of the object (usually a primitive) so it doesn't clip into the object, it always "rotates" around it.

 

One of my driving forces for VP, when I go in to make modifications to tables or the rare cases where I try to make my own table, is to make it angle independent.  Since Primitives have been allowed in VP, this is now very attainable (unfortunately it trades the skills of perfect placement and source material matching with 3D modeling skills).  Take for instance the most recent Scared Stiff table (uploaded by Dozer316, it's a mod of JPS's).

 

Ridiculously amazingly looking table, but hardly any (if any) meshes.  I hold no fault to the authors; a mesh looks only as good as its texturing.  And since you can get photo-realistic with ramps and walls (since they're literally photos), it would take a crazy 3D artist (or maybe a... Dark minded one... see what I did there ;-)) to get that level of realism.  However, the player is limited to the angle the author chose.  If they want to change the angle to suite their desires more, they break the realism, and things can start looking mighty funky.

 

I looked at Scared Stiff because some amazing authors have created it in FP, which means lots of already made and textured meshes that I've easily been porting over to VP for my own use.  Now I admit, I'm not a fan of flashy flashers.  I mean, when I play a table and a flasher goes off, I don't know about anyone else, but I don't see a star burst, or flare effect.  But it's admittedly cool to see on the screen, so for the sake of not re-doing all the graphics, I'm keeping the flashers (for now).

 

As of this writing, I've replaced all the spines, the beast's head, all the leapers, the two boogie monsters, and the four boney flasher holder things.  I've animated the leapers (using code that I'll swap out into my Cactus Canyon table instead of using a ball to mimic physics), which I'm proud of.  I've "animated" the boogie men (not really animated (yet), just tilting, but it looks no worse than the current iteration... although the meshes don't look that great).  BUT, that's not the point of this post, that's just me bragging.  The point of the post is that I think I've figured out a way to tilt the flashers towards the player, regardless of the Backdrop settings.

 

Currently the flashers are flat, so the lower you make the inclination, the flatter the flasher effect is and the more unrealistic it looks.  However, if you put the following code in the table init (or anywhere outside a Sub I suppose), it'll face the flashers towards the player regardless of the Backdrop settings:

FlasherName.RotX = -TableName.Inclination
FlasherName.Y = (dSin(TableName.Inclination)*SizeOfPrimitive) + PrimitiveName.Y
FlasherName.X = PrimitiveName.X
FlasherName.Height = (dCos(TableName.Inclination)*SizeOfPrimitive) + PrimitiveName.Z

Yeah, four lines of code, per Flasher.  Please Note, dSin and dCos are standard functions that take the radians that VBScript gives from a Sin/Cos function and turns it into degrees (which is what we need here); so you need to include that somewhere else in the code.  I can copy it here if anyone is interested.

The first line of code rotates the Flasher so it's always facing the player, but, this will cause it to clip into the object.  We've got to move it's Y position and Height so it stays on the outside of the primitive (which is why we need to know the size of the primitive).

The second line of code moves the Y based on the inclination of the table and the size of the primitive, offset by the location of the primitive.

The third line isn't really needed, but I included it for robust-ness.  This line lets you not have to worry about lining it up in the editor.

The fourth line does the same as the second, but acts on the Height.  Here's an example from the Scared Stiff table I'm working on:

Flasher24.RotX = -Table1.Inclination
Flasher24.Y = (dSin(Table1.Inclination)*75) + Primitive33.Y
Flasher24.X = Primitive33.X
Flasher24.Height = (dCos(Table1.Inclination)*75) + Primitive33.Z + 125

The red balls of the flasher on the table are about 75 VP units big, and it sits about 55 units higher than the Origin of the mesh which is already at 55 (so 55 units from the bottom of the holder to the bottom of the ball, then another 75 units to the top of the ball = 125 units offset).  The position of the primitive is (35, 1503).  Let's say you put the inclination at 5 degrees, that means:

Flasher24 will be rotated to -5

Flasher24's Y position will be dSin(5) * 75 + 1503 = 1509.54

Flasher24's X position will be 35

Flasher24's Height will be  dCos(5) * 75 + 55 + 125 = 254.71

 

Now let's say you put in an inclination of 85, that means:

It will be rotated to -85

The Y will be dSin(85) * 75 + 1503 = 1577.71

The X will be the same

The Height will be dCos(85) * 75 + 55 + 125 = 186.54

 

Is anyone interested in this?  I know the code isn't 100% perfect, but it works on this table at least.

[Les73gTx]

Very interested as I always adjust my tables for my liking. I am a tall guy so I just think they look different to me ... thanks for the awesome post and description

[jpsalas]

Interesting, I'm sure I'll try it

[mfuegemann]

That sounds great. I will try that out for GI flashers too. I think I will place invisible triggers as reference points for the GI flashers.

Maybe the outcome is a table that can be used for FS and Desktop without any changes.

[Shoopity]

That sounds great. I will try that out for GI flashers too. I think I will place invisible triggers as reference points for the GI flashers.

Maybe the outcome is a table that can be used for FS and Desktop without any changes.

Yeah, that's the idea, to hopefully let authors create a table only once and just release some Backdrop settings (or let the player decide for themselves).  It works with any Flasher object; it would probably work for a Primitive too (if someone was using that for some effect for whatever reason).

[StevOz]

Please Note, dSin and dCos are standard functions that take the radians that VBScript gives from a Sin/Cos function and turns it into degrees (which is what we need here); so you need to include that somewhere else in the code.  I can copy it here if anyone is interested.

 

Yes please this all sounds like an elegant solution to the rather tedious moving the flasher manually/play/move again trial and error method.

 

Nice Shoopity!

Edited by StevOz, 09 November 2014 - 12:55 AM.

[Shoopity]

Function dSin(degrees)
	dsin = sin(degrees * Pi/180)
	if ABS(dSin) < 0.000001 Then dSin = 0
	if ABS(dSin) > 0.999999 Then dSin = 1 * sgn(dSin)
End Function

dCos is the same, just replace dsin with dcos, and replace sin with cos.  I'm fairly certain you don't need dCos since Cos is the same as Sin, just 90 degrees difference.  So instead of

dCos(Table1.Inclination)

you could probably just do

dSin(Table1.Inclination + 90)

 

I haven't test that yet so I'm not 100% sure.

 

Also, just a little update for the Scared Stiff table I'm working on, the numbers are a little off, they should actually be:

Flasher24.Height = (dCos(Table1.Inclination)*40) + Primitive33.Z + 100

That is to say, the RADIUS of the primitive is about 40 (since the diameter is 75~80).  And from the Origin of the primitive to the CENTER of the flasher globe (in this particular instance) is ~100 units.

[faralos]

only type of flasher I know is this kind

Attached Files

•  flasher_cartoon.jpg   15.81KB   7 downloads

[unclewilly]

This seems pretty neat.
so essentially with this code all ypu really need is to have the size of the flasher object and the code will place it on the table for you?

[unclewilly]

And if i understand correctly. Rather then figuring out the offset for height from the origin, you could use a static invisible dummy primitive set in the exact center of the primitive flasher and all you would need to know is the size.

And for size you mean height of the flasher primitive?

This could be very nice for building tables as well because you could set all the flashers off to the side of the table so they wouldn't be in the way when building.
Will this take into account the width of the flasher.

Say you have a flasher cap. With the orgin in the center.

Will the flasher object be placed at the orgin. Essentially being cut in half by the prinitive

Ill have to experiment.

[Shoopity]

So take for example the cylinder flashers in the Primitive Template table (which are flashers from FP, right?).  The origin for those are at the base of the primitive.  I would say they're about 55 VP units tall.  So SizeOfPrimitive would be 55.  Of course this also means if you put, say, 90 in for the inclination (so it's the opposite of looking straight down on top of a table), the Flasher would be at the base (which is really where the light bulb is).  But you can account for that in the Height setting of the Flasher by adding, say, 25 at the end.

 

By height, I mean the largest portion of primitive (to avoid clipping anywhere).  So let's pretend you stretched a flasher from the Primitive Template table to be 100 units tall; it's only ~55 units wide, but you would use 100 (maybe a little more to be safe) because it's so tall.

 

And yes, you could definitely put the flashers anywhere in the editor and they would be moved at table run; in fact that's what I'm doing with Scared Stiff since Dozer went absolutely Flasher crazy ;-).  It also means you can move the primitives around without having to worry about adjust the corresponding Flashers too.  Some downsides include having to put code in for EVERY Flasher object you want this effect for; also if you specifically want to adjust it some, you'd have to play with code instead of just moving it in the editor.

 

If all you did was set the RotX to the be -Table.inclination, then yes, it would cut the primitive and look bad, but that's what the other lines of code are for.  You're effectively moving the flasher in a circle around the origin (which is why you need the height/size of the primitive, that's the radius of the circle) so it's always facing the players.

 

In the following screenshot, all I did was change the Inclination from 54 to 4, literally took 2 seconds:

 SS1.jpg   461.31KB   8 downloads    ss2.jpg   299.73KB   9 downloads

 

You can even see with the coffin, in the first shot it's not cutting through it at all, in the second shot it is because rotating it to flat now cuts it through

Edited by Shoopity, 11 November 2014 - 09:12 PM.

[unclewilly]

Thats really cool shoop. Im gonna start using that. Its really not that big a deal doing it for each flasher object.

Just make it a subroutine that passes flashername, primitivename, and size.

That is why i suggested using a dummy pim for each flasher primitive. That way if the orgin is not the center of the flasher you can place the dummy primitive where the origin should be.

Really great concept. Cant wait to try this out.
ill have to check vp10 to see if the properties for the flasher object are the same

Reall cool and will save me much time on desktop conversions

[zany]

Looks REALLY cool Shoopity!!!
 

[xio]

Some downsides include having to put code in for EVERY Flasher object you want this effect for

 

Maybe you can just add them in a FlashersToMove collection and use your code on the elements (for each FlasherName in FlashersToMove ..... Next) ?

[Shoopity]

Maybe you can just add them in a FlashersToMove collection and use your code on the elements (for each FlasherName in FlashersToMove ..... Next) ?

Between that or just doing, you know, smart coding like UW suggested, yeah, you could do this fairly easily the more I think about it.  I'm a decent idea guy and showing proof of concept; I'm not that good or quick and/or efficient implementation.

[unclewilly]

Yes you are shoop.
i am excited to start implementing this.
will save a ton of time for those that release fs and dt for each table. And also allow people to set there own settings in the backd%op.

So i can release a table in fs. And just add the desktop settings in the release. And done.

Will save some room and bandwidth on the vpf server

[dark]

Where did the 3d models for this table come from?  A FP version?  They look pretty decent, I wanted to do these at some point but I guess not much need to.  I think the bone segments could benefit from a higher level of detail especially since in VP they could be rendered static but the collection looks good regardless.  I particularly like the frogs/leapers.

[Shoopity]

Yeah, they're from a FP release.  I downloaded the table from pinsimdb.org.  This is where I'm a little conflicted about releasing a mod.  Dozer already gave his blessing, but I don't have an account at pinsimdb or gopinball.com.  I don't want to upset the original authors by using their well created and textured models without their permission, but I'm not sure how else to contact them (I downloaded the table by using bugmenot.com)

 

I don't know if the models need more detail, or if they just need better texturing (the skull could definitely use some work; there are a lot of unnecessary triangles/faces, it makes getting any sort of baked textured difficult/impossible).  Feel free to play with them as you will dark.  And if you want to see the table in action, you can download it here.

 

***Edit***

 

Opps! I was playing the animating the leapers and coded a way to make them go in slow-motion.  Search the script for a variable called "slowmo".  I may have saved the table when I was playing and left it set at 0.5.  If you want the leapers to be accurate, slowmo should be somewhere around 9.8 (I'm just guessing, since that's related to gravity).

Edited by Shoopity, 12 November 2014 - 06:06 PM.

[Sindbad]

Shoop,

 

the idea is brilliant. I tried to implement it in a VP10 table, but unfortunately it didn't work in FS mode. In VP10, the table.inclination variable always returns the inclination of the DT settings - even if in FS mode. I've opened an new record in the VP10 bug tracker.

[Sindbad]

No bug in VP10. Inclination for FS mode can be found in tablename.InclinationFS. Sorry for the confusion, I didnt know that and there's also no info in the command reference.