Page 9 of 11

Re: Post 1.0 Planning Update

Posted: 10 Apr 2018, 23:14
by austen1000
I can't wait to read those docs. I had originally posted this to ask why OpenMW could not create rerouted, sandboxed versions of MWSE functions to maimtain compatiabilty without compromising security. But, nevermind about it (would delete the post, but, that does not seem to be an option).

Re: Post 1.0 Planning Update

Posted: 10 Apr 2018, 23:31
by AnyOldName3
The question of sandboxing is not open to discussion. As you have seen by now every single OpenMW dev who posted in this thread insists on it.
I've said that I'm still unconvinced that we can get away with sandboxed scripting, and that I'm not even sure defending against potentially malicious scripts should be something we care about. That's pretty far from insisting on sandboxing. As I see it, if someone is determined to write a malicious script, there are bound to be ways of breaking out of the sandbox that we don't anticipate (such as calling functions with weird arguments which make the rest of the engine do weird things until some buffer somewhere is overflown and suddenly the engine jumps into a comment in the script) and without a team of experts, there'll always be something we don't anticipate. It's likely to be partial security giving the illusion of complete security, which is likely to make users sloppy about what they download.

Re: Post 1.0 Planning Update

Posted: 11 Apr 2018, 02:57
by Chris
AnyOldName3 wrote:
10 Apr 2018, 23:31
As I see it, if someone is determined to write a malicious script, there are bound to be ways of breaking out of the sandbox that we don't anticipate (such as calling functions with weird arguments which make the rest of the engine do weird things until some buffer somewhere is overflown and suddenly the engine jumps into a comment in the script) and without a team of experts, there'll always be something we don't anticipate. It's likely to be partial security giving the illusion of complete security, which is likely to make users sloppy about what they download.
The same can be said about a CPU's protected mode (which restrict what you're allowed to do with the CPU) or virtual memory (which restricts what you're allowed to do with memory). People still find ways to bypass restrictions all the time, but they're still a useful protection measure. This applies not only to malicious code, but bugs as well. Bugs would be so much worse if they were allowed to wantonly read/write any memory on the system, or execute any CPU opcode. A program crashing in Windows 3.1 is a very different experience than a program crashing in Windows XP/Vista or Linux. It doesn't have to be perfect to be better.

But there's also more to it than that. By abstracting the underlying system away, we can actually provide more features when we control what mods can actually do. Automatic resource management (we control when resources come in and out of existence, when they can be shared/reused/etc), resource virtualization (a particular resource may not actually exist, or only exists for spuratically, but we can simulate enough for the mod to work uninterrupted), system compatibility (a particular system doesn't directly support what the mod wants to do, or different systems do the same thing in different ways? we can provide compatibility layers to ensure it works everywhere), the list goes on. If mods can dig out of the sandbox to see what's really going on behind the scenes, even optionally, and starts touching things at a lower level, those guarantees can no longer be made.

Re: Post 1.0 Planning Update

Posted: 12 Apr 2018, 15:32
by Jemolk
Chris wrote:
11 Apr 2018, 02:57
But there's also more to it than that. By abstracting the underlying system away, we can actually provide more features when we control what mods can actually do. Automatic resource management (we control when resources come in and out of existence, when they can be shared/reused/etc), resource virtualization (a particular resource may not actually exist, or only exists for spuratically, but we can simulate enough for the mod to work uninterrupted), system compatibility (a particular system doesn't directly support what the mod wants to do, or different systems do the same thing in different ways? we can provide compatibility layers to ensure it works everywhere), the list goes on. If mods can dig out of the sandbox to see what's really going on behind the scenes, even optionally, and starts touching things at a lower level, those guarantees can no longer be made.
Now this...This is an excellent point. You're actually swaying me with this. And I do agree with Scawl's cynical comment that if you give people the ability to shoot themselves in the foot, plenty of them happily will. All right, I suppose I'm convinced.

Re: Post 1.0 Planning Update

Posted: 13 Apr 2018, 15:28
by scrawl
Regarding graphics: That is one reason why I want to hand over the document to scrawl before we publish it, because graphics aren't my strong point and he is our resident expert on that topic.
Sure, I could write a blurb on that topic. I suppose most of my evil plans can already be gleaned from little bits and pieces strewn about the forumforum, wiki and bug tracker, but they'll be hard to piece together like that. Almost all of my ideas are actually not at all dependent on the ESX format nor editor support, so I think I could put together a plan for those before you've finished your document. The gist of it all is that we provide generic frameworks for modders to ruin their game put to use, such as post processing effect files and custom object shaders. That way we reject all responsibility don't have to keep on top of all the new graphics techniques that come out every other week and instead have others implement them for us.

Re: Post 1.0 Planning Update

Posted: 13 Apr 2018, 16:04
by AnyOldName3
One point that I'd like to make regarding the proposed post-processing system is that it would be good if effects could request that the engine renders the scene with multiple view directions such that it can have a cubemap or whatever and then do a reprojection like a 360° view (as seen in https://github.com/OpenMW/openmw/pull/1548) or something esoteric that people who sit the wrong distance from the screen for their FOV setting tend to like (as seen in viewtopic.php?f=3&t=5088). If this isn't integrated, then we're likely to end up with multiple systems that do post-processing without sharing code.

Re: Post 1.0 Planning Update

Posted: 13 Apr 2018, 20:46
by Chris
Certain post-processing effects will depend on the way the engine renders and the data provided. Motion blur, for instance, depends on the engine rendering a velocity buffer. Screen-space reflections depends on accessing the previous frame (taken at a particular moment of the render) as well as the previous camera position/orientation (along with the current camera position/orientation).

Re: Post 1.0 Planning Update

Posted: 14 Apr 2018, 07:53
by Zini
scrawl wrote:
13 Apr 2018, 15:28
Regarding graphics: That is one reason why I want to hand over the document to scrawl before we publish it, because graphics aren't my strong point and he is our resident expert on that topic.
Sure, I could write a blurb on that topic. I suppose most of my evil plans can already be gleaned from little bits and pieces strewn about the forumforum, wiki and bug tracker, but they'll be hard to piece together like that. Almost all of my ideas are actually not at all dependent on the ESX format nor editor support, so I think I could put together a plan for those before you've finished your document. The gist of it all is that we provide generic frameworks for modders to ruin their game put to use, such as post processing effect files and custom object shaders. That way we reject all responsibility don't have to keep on top of all the new graphics techniques that come out every other week and instead have others implement them for us.
By any means. Go ahead. There are a few specific topics I need your input for, but we can handle that once I have the complete list.

Re: Post 1.0 Planning Update

Posted: 14 Apr 2018, 09:15
by scrawl
One point that I'd like to make regarding the proposed post-processing system is that it would be good if effects could request that the engine renders the scene with multiple view directions such that it can have a cubemap or whatever and then do a reprojection like a 360° view (as seen in https://github.com/OpenMW/openmw/pull/1548) or something esoteric that people who sit the wrong distance from the screen for their FOV setting tend to like (as seen in viewtopic.php?f=3&t=5088).
In the EffectCompositor, you can already request as many renders of the main scene as you want. We just need to add a directive that adjusts the camera orientation for each cube face. There are many more possible directives that could be useful for all sorts of effects, and if you find a neat one I haven't thought of you could always make a PR. To start with I would work off of the Ogre3d compositor system, which is actually quite nice concept wise if you ignore its slow and messy implementation.

A small problem I see with effects that change the projection would be that screen raycasts (e.g. using your cursor to drop an item in the world) will no longer match what's seen on screen. The center of the screen will probably refer to the same point still and work fine, but anything else will not.

Re: Post 1.0 Planning Update

Posted: 14 Apr 2018, 12:13
by AnyOldName3
Would it be reasonable then to let effects have an optional parameter which is a function to convert rays from one version of screen space to another?