3889 replies to this topic

[toxie]

Ramps: The twist is that the height offset will be applied 'smoothly' instead of a 'flat' increase in height. So in that sense it even makes sense to have both things (the two heights and the control point offset) still intact.

So for a whitewater style ramp the height offset mechanism should work perfectly: You just set up start and end heights where they should actually be attached to the rest of the table, then modulate the height for the control points inbetween (negative and positive values work both, of course).

Apart from that, let me know if there is any weirdness with the new ramp code, as i also optimized it a bit on the way to have slightly faster rendering.

 

Ball spin: The previous hack was replaced by a new hack, so overall its still far from perfect, but the new hack should have less sideeffects than the old one, plus its should resolve fast and slow spinning balls, as long as they don't move 'too much' around.

[gtxjoe]

A single ramp with adjustable height for each control point.  Awesome!!!!

 

To UW's point

Height offset - is it relative to the bottom height, top height or average of both?

 

So if I wanted to build a ramp that starts at 0, rises to 200 and then ends at 100, should I:

 

Set ramp bottom height to 0

Set ramp top height to 100

Add middle control point and set height offset to 200

OR

Set ramp bottom height to 0

Set ramp top height to 0

Add middle control point and set height offset to 200

Set top control point height offset to 100

OR 

something else...

 

 

Is there a reason for choosing relative offset, why not simply specify actual height for these control points?  The control point height could be greyed out/hidden for the top and bottom control points, i.e

Set ramp bottom height to 0

Set ramp top height to 100

Add middle control point and set height to 200

 

 

BTW, nice touch on identifying top vs bottom of the ramp

Edited by gtxjoe, 25 June 2015 - 05:03 PM.

[fuzzel]

The reason for the relative offset is that the core handling was designed for the old simple ramps. It's really tricky to apply the absolute height to each control point.
So for your example: set bottom to 0, top to 100, add another control point in the middle of the ramp and set the height to 150 ( (100-0)/2)+150=200). That's the tricky part at the moment and I don't know if it will be easily solvable.

[KieferSkunk]

From a usability standpoint, relative heights are good in that you can adjust one or two properties of the overall ramp and have the in-between points move along with it - same as with X and Y coordinates.  But they're confusing in that there are two different "base heights" for a ramp, so in order to place a new control point at the height you want, you have to interpolate its distance between "top" and "bottom" to determine what its base height would be.

 

I was going to propose that you instead make a "base height" for the whole ramp and then make each individual control point (including the top and bottom ends) an offset from that height.  However, I realized just as I was about to click "Post" that this would actually make development harder - if a developer wants to make a smooth ramp that, say, rises from 0 to 100, they'd have to then position every individual control point at some offset from the base height, or VP would have to perform that interpolation for them automatically.  Relative-from-slope actually makes the most sense - for most ramps, you're simply not going to need to be concerned with the offset at any individual point.

 

@gtxjoe: If you specify an absolute height for an individual control point, you have two issues: (1) The control point has to have a concept of an "optional" parameter that can be null/not-set in order to obey some default behavior, which complicates the data model, and (2) You then have to answer questions about what to do if the ramp as a whole changes height (you change the top or bottom height parameter).  Conceptually, it also mixes concerns - that point on the ramp is now specified relative to the TABLE, so it's now a table concept and not really part of the shape of the ramp.

 

Think of it from a manufacturing standpoint: When a real table developer designs a ramp, they will definitely think about the height of that ramp in terms of the table - for example, the lowest dip on the Whitewater ramp should be, say, 8 mm from the table surface.  But the CAD file for the ramp describes the shape of the ramp itself in isolation, because that's what's going to be built.  So given that the top of the ramp is, say, 70 mm from the surface, the vertical extent of that dip is 62 mm.  If you want to make the top of the ramp sit at 80 mm but keep the dip at the same height relative to the table, then the dip now has to be 72 mm from the top.  And so on.

 

So basically, I think the VP devs are doing the right thing by making you describe point height relative to the slope of the ramp itself rather than making it absolute (relative to the table).  It simplifies the design and allows you to treat the ramp as a complete, singular object that resides in space within the table.  It's a clean concept.

[gtxjoe]

Okay, I think I understand.  So the offset value is applied to the calculated height of that control point.  Back to the example.  If I want a ramp to start at 0 and have midpoint at height 200 and at top point at 100, I can do any of the following:

 

Set bottom height to 0

Set top height to 0

Add control point in the middle of the ramp and set height offset to 200

Set top height offset to 100

 

OR

 

Set bottom height to 0

Set top height to 100

Add control point in the middle of the ramp and set height offset to 150  (the default height would have been 50, so I add 150 offset to make it 200) 

 

OR

 

Set bottom height to 100

Set top height to 100

Add control point in the middle of the ramp and set height offset to 100 (the default height would have been 100, so I add 100 offset to make it 200) 

Set bottom height offset to -100 (the default height would have been 100, so I add -100 offset to make it 0) 

 

@Kiefer, Good point.  You would need maybe an "Enable Offset" checkbox, but you are right if you change the top/bottom height after creating the custom ramp, what happens to all the specified custom points- do you keep them intact or shift them accordingly...

 

Edited by gtxjoe, 25 June 2015 - 07:23 PM.

[KieferSkunk]

The simplest of those would be the second option.  In general, you will probably still want to have as few control points as possible to achieve your goal, and as few individual offsets as possible.

[fuzzel]

I can just second that. Another reason why you shouldn't use too many control points is performance on low-end systems. More control points means more polygons, you can adjust that with the details slider but even with the lowest details you will have more polys. It all depends on the actual look of the ramp you want to build.

[kiwi]

Absolutely amazing this new feature, and if in the future it will be possible to adjust the width of the ramp at every point, will be Super Awesome!

 

Thanks!!

 
The top of the ramp visually seems closed by a wall.

 

 

Thanks

 

Max

[fuzzel]

Thanks Kiwi! Yes I saw this myself too...Unfortunatly you have to wait till next week because Toxie and I don't have much time at the moment to fix this.

[gtxjoe]

I was messing with the new ramp feature last night. Corkscrew ramp up then across then corkscrew ramp down

Anyways I got it to work but as the ramp got longer and longer I had to guess what the calculated height would be and the guess what offset I should apply. I had know idea if the ramp was accurate (probably not) but i was able to make it look good. Trial and error should be fine for most real ramps but if there is a way to display the calculated height of control point when you select it. It would make determining an offset value much easier

Also+1 on the adjustable width request. As I was building the ramp I would love to be able to flare out the entrance and exit of the ramp

Anyway thanks again - this was a nice surprise feature update

[fuzzel]

Well it is possible to use an absolute height for each control point but it would break all current VPX tables. The old code calculates the height by interpolating between the top and bottom height of the ramp. If we change the code in that way that the control points hold the height information then all old ramps from the current tables would lay on the playfield because the control points have a height=0. That would mean you have to rebuild all ramps again

[hmueck]

Well it is possible to use an absolute height for each control point but it would break all current VPX tables.

First, thats what beta versions are for!

Second, if you want, you could add a version no. to the vpx files and if it's below rev.X, the height will not be zero, but calculated by VP10.

[gtxjoe]

I am convinced now that offset is the way to go.  If you adjust the bottom or top height of a ramp, the offset requires no change.  Absolute values would all have to be adjusted

 

In my previous post I was just asking if the calculated height for the control point could be displayed as read only to help with making ramp adjustments 

Edited by gtxjoe, 26 June 2015 - 02:22 PM.

[fuzzel]

I understood you but that's not feasible.
I can offer you another solution: i change the ramp on a way that there is no top and bottom height but only a height offset which is applied to all control points.This way you can raise or lower a ramp without editing every control point. The height of a control point is the absolute height plus height offset. This would be incompatible but I would make a special conversion VPX version you could use to apply the new height information to all control points without recreating them.This version wouldn't play a table just convert them.
I understood you but that's not feasible.
I can offer you another solution: i change the ramp on a way that there is no top and bottom height but only a height offset which is applied to all control points.This way you can raise or lower a ramp without editing every control point. The height of a control point is the absolute height plus height offset. This would be incompatible but I would make a special conversion VPX version you could use to apply the new height information to all control points without recreating them.This version wouldn't play a table just convert them.

[toxie]

i also think that the offset is a good strategy.

 

as for the closed ramp: apparently i optimized it incorrectly.  :/

will have to wait until tuesday though (most likely) as i don't have much time this weekend.

[KieferSkunk]

fuzzel: When you say "that's not feasible", could you clarify what you think isn't feasible?  I think the request was to simply have an extra bit of display on the UI for a control point that tells you what the effective height of that point is.  You should easily be able to calculate that on the fly as:

 

(bottom + (top - bottom) * (point_pos / length) + offset)

 

Just display that in a read-only field in the control point's properties and update it when the point moves or is updated.  Doesn't involve actually changing any properties on the fly.  This should be a very easy UI feature to add, I'd think.

 

As for "single height": This was the alternative I was about to suggest the other day but then backed away from.  Here's why: Most ramps are going to be more or less linear in slope - they'll have a definite top and bottom height, but there may not be any need to adjust the height of the ramp at any individual point along the way.  But if you go the route of giving the ramp an overall height that applies to the entire ramp, it forces you to describe the ramp's slope along every control point, either manually, or through some "magic" using the endpoints of the ramp and "overridable/automatic" properties.  Trust me, you don't want to go that route - that will make things much more difficult and confusing for your users.

 

Your current strategy of doing an interpolated height and an offset at that point is fine.  I think you should just allow people to see what the interpolated height is at any given point along the ramp while they're designing it, and it's very easy and cheap to calculate.

 

 

BTW, to clarify part of my formula there: "point_pos / length" is my uninformed speak for "Where is this control point along the ramp between the bottom and top endpoints?"  For example, if you're working with a point that is 3/4 of the way toward the top end of the ramp, its "pos/length" is 0.75, and its base height would be 75% of the way between the bottom and top height.  If you've set an offset on top of that, then you'd get the point's actual, absolute height on the table, only as a display element, not as a stored property.  (Besides, VP has to calculate these things anyway when it renders the table.)

Edited by KieferSkunk, 26 June 2015 - 04:01 PM.

[jimmyfingers]

I understood you but that's not feasible.
I can offer you another solution: i change the ramp on a way that there is no top and bottom height but only a height offset which is applied to all control points.This way you can raise or lower a ramp without editing every control point. The height of a control point is the absolute height plus height offset. This would be incompatible but I would make a special conversion VPX version you could use to apply the new height information to all control points without recreating them.This version wouldn't play a table just convert them.

I think this would pose potentially more problems than the solution as it stands because without a top or bottom height and only control point information, no scripting ability to lower and raise ramps seems possible.  There are lot's of tables and scenarios where ramps need to be lifted or lowered (pivoted from one end and not just the whole thing raised or lowered either).

 

I think a lot of contemplation around the impact and ramifications of more ramp changes is prudent not just for converting tables or breaking existing VP10 WIPs but hitting brick walls down the road that weren't thought of during these potentially quick but impactful ramp changes.  I also don't think creating and using collidable primitives as a work around for these potential issues is desirable either for a few reasons.

[Shoopity]

I came to this thread today to ask a question/feature request and saw that you just added the ramp offset ability and thought it was cool that my request is in the ball-park of a feature that was just added.  How possible would it be to add this off-setting ability to a control point of other objects, or just set the Z/height coordinate of an individual control point?

 

I specifically am desiring it for the Flasher object, but it might be interesting to apply it to, say, a Wall or a Light.  The reason I had the idea for a Flasher is because Frenetic is doing some amazing work on America's Most Haunted; he had the idea of using two lights inside the ghost Primitive to light it internally as opposed to use the Primitive image swapping ability I use in my VP9 version.  His implementation opens up a slew of possibility as far as color fading and intensity is concerned, but that effect is broken in two places.  If the angle of the table is set too low, it no longer looks like one light (he used on Light object at the base, and one about half way up); when the ghost rotates and his non-light (or less lit) arm rotates in front of the highly lit body, the light doesn't get "covered up".

 

I don't know if the second issue fix-able (In this particular instance, I think we'd need to break the body and the arms of the object and set the opacity of the arms to 1 since the whole object has a fairly high opacity), but the first issue might be better implemented if we could make a dome shaped Flasher (or light for that matter).  So now we can make shaped Flashers, and we can rotate them on the three axis; we can make a curved Flasher and rotate it, but it's still a flat plain.  If we could define a height for each control point, then we could an object with some "volume".  Or, is this requesting that we make a Mesh editor in VP?

 

Would it be easier to make a primitive emit light?

 

Also while I'm here, currently if an object's material is anything less than 1 opacity, it allows the same amount of light to pass through regardless if it's set to 0.99 or 0.1, as far as the light emitted by a Light object is concerned.  Is this something being worked on, planned for a future release, just a limitation of the current engine, etc.?

[fuzzel]

fuzzel: When you say "that's not feasible", could you clarify what you think isn't feasible?  I think the request was to simply have an extra bit of display on the UI for a control point that tells you what the effective height of that point is.  You should easily be able to calculate that on the fly as:

 

(bottom + (top - bottom) * (point_pos / length) + offset)

 

Just display that in a read-only field in the control point's properties and update it when the point moves or is updated.  Doesn't involve actually changing any properties on the fly.  This should be a very easy UI feature to add, I'd think.

 

As for "single height": This was the alternative I was about to suggest the other day but then backed away from.  Here's why: Most ramps are going to be more or less linear in slope - they'll have a definite top and bottom height, but there may not be any need to adjust the height of the ramp at any individual point along the way.  But if you go the route of giving the ramp an overall height that applies to the entire ramp, it forces you to describe the ramp's slope along every control point, either manually, or through some "magic" using the endpoints of the ramp and "overridable/automatic" properties.  Trust me, you don't want to go that route - that will make things much more difficult and confusing for your users.

 

Your current strategy of doing an interpolated height and an offset at that point is fine.  I think you should just allow people to see what the interpolated height is at any given point along the ramp while they're designing it, and it's very easy and cheap to calculate.

 

 

BTW, to clarify part of my formula there: "point_pos / length" is my uninformed speak for "Where is this control point along the ramp between the bottom and top endpoints?"  For example, if you're working with a point that is 3/4 of the way toward the top end of the ramp, its "pos/length" is 0.75, and its base height would be 75% of the way between the bottom and top height.  If you've set an offset on top of that, then you'd get the point's actual, absolute height on the table, only as a display element, not as a stored property.  (Besides, VP has to calculate these things anyway when it renders the table.)

Yes after thinking about it this is the best solution. "Not feasible" was a bit too general. I ment it's not feasible to add the information to the existing UI properties of a control point. But adding a read only is simple ofcourse. So I think we all have an agreement that we let the ramp parameters as is and I just add the extra height information as a read-only element to the control point property pane.

[STAT]

( i wonder, when will be VP10 Tables here in an official Downloadsection like all others ? )