834 replies to this topic

[mukuste]

 

Thanks Fuzzel! you're the best  , now you expect more developments such as "primitives colidable"  

 

They're collidable currently (at least in 9.9).  However, it seems you have to load a mesh first, and also turn off "Is Toy".  I haven't been successful in dropping down a primitive, making it collidable, turning off the is a toy, and it being a wall; however, once I load a mesh into it, then it's collidable (sounds to me like the default primitive doesn't have... normals?)  Admittedly it's not 100%, but it's there somewhat.

 

Yes, in VP9, the default primitives were not collidable. I've since fixed that for VP10. That said, the old collision bugs with primitives still exist, but they will also be fixed at some point.

[javier1515]

 

Thanks Fuzzel! you're the best  , now you expect more developments such as "primitives colidable"  

 

They're collidable currently (at least in 9.9).  However, it seems you have to load a mesh first, and also turn off "Is Toy".  I haven't been successful in dropping down a primitive, making it collidable, turning off the is a toy, and it being a wall; however, once I load a mesh into it, then it's collidable (sounds to me like the default primitive doesn't have... normals?)  Admittedly it's not 100%, but it's there somewhat.

 

 

 

Sorry, I expressed wrong, I mean moving primitive.

[fuzzel]

 

Always at your service
 
Nearly all lights on the screenshot are bulbs. You can color them as you like. In the trough you see the new mesh ball.

Will object shadows still be acheavable with the new bulbs?

 

No not yet. For creating shadows the complete render engine must be changed first. At the moment we have a mixture of the old fixed function pipeline (like VP9.9) and shaders (new lights and the mesh ball at the moment). For creating shadows/defered lighting and/or ambient occlusion every VP element must be replaced with a shader first. This will come but I don't know if this will happen in VP10.0.

Edited by fuzzel, 02 June 2014 - 09:07 PM.

[ICPjuggla]

Always at your service
 
Nearly all lights on the screenshot are bulbs. You can color them as you like. In the trough you see the new mesh ball.

Will object shadows still be acheavable with the new bulbs?

No not yet. For creating shadows the complete render engine must be changed first. At the moment we have a mixture of the old fixed function pipeline (like VP9.9) and shaders (new lights and the mesh ball at the moment). For creating shadows/defered lighting and/or ambient occlusion every VP element must be replaced with a shader first. This will come but I don't know if this will happen in VP10.0.

No worries, was just wondering..

With the new lights can we add our own texture? Was thinking we could maybe do the shadows that way.. :-)

[mukuste]

Since the topic came up again in the physics thread, and people want some sort of 10.0.0 relatively soon, I guess we should discuss what kind of release and compatibility plan we should adopt.

 

Some terms, just so we talk about the same thing: backward compatibility means that a new VP versions plays tables created for an old version correctly; forward compatibility means that an older VP version will still play tables created in a newer version correctly.

 

It's clear already that VP9 and VP10 won't be compatible to each other in either of these senses; the new physics engine alone ensures that VP9 tables won't play in VP10 and vice versa. No discussion here.

 

Should 10.0.0 be forward compatible? Probably not, it would mean that we cannot add any new features in 10.0.X except for bugfixes, editor improvements which don't impact the player, or very minor visual changes which can't cause glitches in the old version. So that's very limiting, at least if we want a 10.0.0 release soon. If we take more time and build more of the wishlist items into 10.0.0 already, then I could see it happening, maybe, but I don't think it's worth the effort with how easy it is to upgrade.

 

What's definitely clear is that all 10.0.X versions must be backward compatible to 10.0.0. It would be crazy if the first VP10 tables became incompatible already a few releases later.

 

In practice this would mean: as soon as a new 10.0.X version is released, everybody should upgrade from the older 10.0 versions to that newest one since it will still play all older VP 10.0 tables fine, and new tables might require the new features.

 

And for development it means: we have to put all breaking changes that we want to have in VP 10.0 into the initial 10.0.0 release; anything that might break old tables has to happen now, not later. It's ok, however, to postpone new features to a later release as long as they preserve backward compatibility (e.g.: a new Rubber object; adding it won't break old tables since they simply don't have it).

 

And for VP 10.1.0? I have no idea whether it should/will be backward compatible with 10.0 or not. I can imagine that that will be the version with a completely overhauled rendering engine, in which case compatibility probably won't happen. But it will be a pretty long time until we get to that point.

 

Happy to hear any opinions on this.

Edited by mukuste, 02 June 2014 - 10:18 PM.

[LoadedWeapon]

In practice this would mean: as soon as a new 10.0.X version is released, everybody should upgrade from the older 10.0 versions to that newest one since it will still play all older VP 10.0 tables fine, and new tables might require the new features.

 

And for development it means: we have to put all breaking changes that we want to have in VP 10.0 into the initial 10.0.0 release; anything that might break old tables has to happen now, not later. It's ok, however, to postpone new features to a later release as long as they preserve backward compatibility (e.g.: a new Rubber object; adding it won't break old tables since they simply don't have it).

I think this would be best... pretty much what we did with 9 And sounds like the most logical path...

[unclewilly]

That sounds like a plan, but don't do anything that will limit you.
I'd much rather update tables then limit you guys in what you can do

[The Loafer]

I agree with everything above, would just state be careful you (the devs) don't paint yourselves in a corner because of an earlier than should be release of vp10. Ie you release what you think is the vp10 that should be compatible moving forward with future releases, but something new that comes up that becomes apparent should have been in and now it breaks stuff if you add it.

You guys show above average planning, we can see this in the detailed plan above, so I don't think its an issue at all. but I know there has been pressure to release sooner rather than later. I may want cool new features but that's because I am a greedy bastard , and if I can speak for most, it is simple exuberance on our part due to the great leaps we have seen of late. I think the majority also realize that "its ready when its ready" is not only a pretty good idea, it's the only way to go.

So no pressure, when you guys feel its at a point where anything you add is not core but features, then you will find us ready for the release.

[Practicedummy]

I agree with the Loaf on this. To quote the Great Gabe 'Gabemeister' Newell: "A game that is late is late for just a little while, but a game that sucks will suck forever".

[dyopp21]

Being a player and not a dev, I don't know that my word is worth snot but I wholeheartedly agree with Loaf and Practice D. above.  Get all the features in you want no matter how long it takes.  We already know it won't suck with the excellent devs we have on this project.

 

I only hope the developers road ahead is wide and well-paved.

[gtxjoe]

I can't decide  I think it would help if we had a short list of main features for each of these major SW releases

 

1) Must-have features for 10.0.0 release

• Physics overhaul
• Lighting overhaul
• ...

2) Additional features planned for 10.0.x (with backwards compatibility in mind)

• Rubbers object
• ...

3) Features longer term  (10.1.x or 11.0.0).  Backwards compatibility not guaranteed

• Rendering Engine overhaul

Edited by gtxjoe, 03 June 2014 - 05:38 PM.

[lio]

Take as much time as you need to add any groundbreaking features to 10.0.
I think it's better to break what needs to be broken in the inital release.
I think 10.x should largely be backwards compatible to 10.0 and if something comes along that breakes compatibility again in a big way (say a completely new rendering engine) call it 11.0
Personally I am mostly hoping for the new physics and some editor convenience features (like a proper rubber and ball guide object, collidable primitives, shadow casting primitives) for 10.0

Edited by lio, 03 June 2014 - 06:27 PM.

[fuzzel]

Just a small update: I again changed the lights. The radius was replaced by a falloff option. If you load a VP9 table the radius is converted to this new falloff option. The falloff option indicates how fast the intensity from the light source will drop. In the first screenshot you see how this is shown in the editor: A red circle indicates the falloff radius from the center of the light. You can move the center and the falloff circle will follow and you can disable the falloff radius by unchecking the "Show" checkbox for each light. The falloff is relative to the boundaries of the light element (read: there won't be light beyond the boundaries).

The next screenshots show a bulb light scaled by factor 2.5 with different falloff values (50,80 and 150).

Attached Files

•  LightFalloff.jpg   137.72KB   22 downloads
•  FallOff50.jpg   1.44KB   18 downloads
•  FallOff80.jpg   1.52KB   17 downloads
•  FallOff150.jpg   2.07KB   19 downloads

Edited by fuzzel, 04 June 2014 - 08:31 AM.

[mukuste]

Neat! That rightmost screenshot reminds me that we really want to have gamma-correct/linear color space rendering (http://http.develope...gems3_ch24.html). I thought we could put that off until we overhaul the entire rendering engine (more ideas for that: HDR rendering, per-pixel lighting, physically based shading), but maybe the light shader can be special cased to do it already, it's a bit ugly how it fades out now.

 

Also, a suggestion about the "Show" checkbox: maybe remove it and show the red circle only if the light is selected? Should be less fiddly and show the circle only when the user is actually interested in tweaking it, while keeping the display clean when the light is not selected.

[unclewilly]

Very nice fuzzel

[fuzzel]

Neat! That rightmost screenshot reminds me that we really want to have gamma-correct/linear color space rendering (http://http.develope...gems3_ch24.html). I thought we could put that off until we overhaul the entire rendering engine (more ideas for that: HDR rendering, per-pixel lighting, physically based shading), but maybe the light shader can be special cased to do it already, it's a bit ugly how it fades out now.

 

Also, a suggestion about the "Show" checkbox: maybe remove it and show the red circle only if the light is selected? Should be less fiddly and show the circle only when the user is actually interested in tweaking it, while keeping the display clean when the light is not selected.

The fading of the rightmost screenshot comes from the fact that the falloff value is significant higher than the actuall light boundaries. Because the boundaries limit the fading there is no space left to fade nice and clean.

The falloff value is also used with light inserts and how the image of the insert is lit. Depending on the image it can help to illuminate an insert.

 

Good suggestions. I've already changed that

[unclewilly]

Very curious to see how this works and looks with an insert. Very very nice

[fuzzel]

The funny thing is you can still use the old technic by switch the images as long as you don't switch on a light

Edited by fuzzel, 04 June 2014 - 10:05 AM.

[unclewilly]

The way these lights are progressing . We may not need the old method. The way your screen shot looks seems pretty realistic to a bulb in the middle illuminating an insert.
Would just need a fading flasher overtop to create a halo
D's it fade in and out that way shrinking and growing from t&t&e center point

[fuzzel]

It does...but I think it's better if you play around by yourself Here is a small demo I've just compiled from the main trunk. Because VP10 doesn't support commands like triggersingleupdate or topvisible you can't just load and play VP9 tables anymore. For porting a VP9 table you have to remove the tiggersingleupdate calls and change "topvisible" to "visible".

Attached Files

•  VP10-LightsDemo.zip   2.25MB   50 downloads