About those particles moving at the speed of light and colliding (now I seriously wonder if their relative speed will be 2*c..., should have payed more attention to physics at school :P) in 2): It depends a lot on how you handle that collision. The naive approach would be to move entity foo first and entity bar second and after each movement, check if their is any intersection with another collider and get how far inside they are in the direction of the previous movement and then move them back accordingly.
Now with a sequential approach, foo will always reach his destination, while bar will always get stuck inside and be moved back. When doing the updates multithreaded however, it sometimes could also be the other way around, resulting in different positions for both. Or in the worst case, when both do the collision check at the same time, the collision would probably not be detected and they would stay inside each other and generate black holes or something. The speed part however is the real problem. Sequentially foo would just be placed somewhere far away first and then the same for bar without any collision, even if they should collide. Multithreading wouldn´t really make a difference.
The solution some physics engines hide as continuous collision detection is to stretch foo and bars bounding boxes along the whole way they are supposed to go and make intersection tests of those two bounding boxes and if they cross and according to their real speed and size would collide there, foo and bar would be placed accordingly. This behaviour should then be pretty much the same in sequential and multithreaded implementations, but multithreaded will need to synchronize their desired speed inbetween or do the calculation based on the previous speed. Thinking about it, sequential would also have to determine the speed of both before moving...

Sid will tell you more.


Good for you, because if you did, I am still mindfucked on how it would work with our goals for Rayne, which do not include the world and domination!

PS: I btw think that we DO update the entities multithreaded, at least in theory... and not sure how we handle updates depending on each other...

You hinted at some kind of black hole there.

FIRST OF ALL, that's about my PERSONAL goal of making the place a little less crowded so everyone has more room to do whatever it is that they do. My personal goal does not require anyone else's to be aligned with it nor it is exclusive of other's goals. And it's not for domination. How can ,do you suppose, one dominate DEAD people? They are dead and in peace not dominated and in misery. For short, my plans about the number of people on the planet is NONE OF YOUR BUSINESS.

Now about entity updates. As you can read from my previous post i already convinced myself it does not matter if it's parallel or sequential from the user stand point. By user i mean the one's using the engine to make a game, not the ones that just play that game. It only matters from engine developers' stand-point,obviously, because of completely different implementation. I suppose user's ways of moving the entities would not change by how the engine actually handles that movement, though maybe the results of may that movement slightly change, but it's so slight that it does not matter. What matters is one of these ways either performs a lot faster, or adding and maintaining the other in the engine's code-base is a lot easier(Maybe both in one them, if that's the case then PARTY, but it don't think it is in this instance). I am not sure if the performance gain is worth the complexity but, of course, you know better.

Oh and yes, I'd like Sid to tell me more.


I am guessing you are more on the graphics side and Sid covers the lower-level side?

3

Jesus, someone needs to re-read the mission statement...


Anyhow, let's cover spinlocks real quick. In Rayne they are implemented as an atomic flag that a thread compares and swap against a true value until it returns false. Here is pretty much the whole code:



If you really want to put a computational complexity on it, then it's O(1) in the best case and O(∞) in the worst. To give you a better answer, as long as the lock can't be acquired, the thread will burn 100% of all CPU cycles that it gets.
They really are only good if held for a minimal time, ie for less CPU cycles than the OS needs to schedule your thread out of and back to an active CPU. If in doubt, don't use a spinlock.


So, about entity updates. They are done in parallel, though you can tell the engine that your entity depends on the state of others so that it won't update until after its dependencies have been updated (a bit like PROC_LATE and PROC_EARLY in gstudio, but with more flexibility). That alone will, of course, not stop the engine from moving two entities into each other at the same time, because putting your entities in a dependency chain would be, quite frankly, stupid (unless your goal is to mitigate all performance improvements).

However, collision is a bad example since you ideally want to use something like bullet for these kinds of things. Rayne doesn't keep sufficient data for fast collision detection, nor do we want it to. There is a c_trace() equivalent, but it's slow and requires parts of the scene to be locked and the entities within it to synchronize with each other. Bullet on the other hand stores collision hulls and scenes in an ideal format for collision detection, and it also provides you with a multithreaded and GPU collision solver, and Rayne picks a renderer that is compatible with OpenCL, so ideally you want to use that path.

Anyhow, fast moving objects are a problem one way or the other, like Nils said, physics engines try to mitigate these problems using CCD, but in reality you want to keep tabs on your objects velocity and avoid small objects. Simulating bullets is a bad idea one way or the other, and should probably be avoided.

But moving away from moving entities around (see what I did there?), exchanging state between two objects is generally speaking not a concern. Though, you do have to do manual locking in these cases, unless you told the engine about the relationship between the entities (which you should in case of long running dependencies). Obviously Rayne doesn't have the required knowledge about your games execution to do this automatically, so you'll have to help it out manually there.
Usually though these things are more hierarchical, AI for example: Your have entities that are part of a squad and a squad manager that keeps tabs on them while the general AI manager keeps tabs on the squads and player. These hierarchies can be expressed by parent/child relationships and if they are, the engine will take care of updating them in the right order (ie parents are updated before any of their childs are updated, so childs accessing their parents or a parent accessing their childs during their update is guaranteed to work).
If you need it more sophisticated, for example because you want a birds eye view of everything happening, well, in this case you can just plug into the engines event tap: We need to do that too after all, and so there are interfaces for this. For example, the trigger zones are implemented that way: Instead of polling every entity every frame, it just waits to be notified about entities updating themselves in its vicinity (where vicinity is defined by the acting scene manager)


No, the floating point errors are something different entirely. If you detach your movement from the FPS by multiplying it with the delta time, but the delta itself varies (because the frame are varying in length), then you will end up accumulating floating point errors in a different way each time you run your application. A solution to this is a fixed time step, not more frames.

Hey Sid, with Rayne's day-one support for VR I though this might be a good look for you guys. With Valve looking to put a foot in the VR future, than working with a dev team on a up coming engine like yours would be cool. A Small engine built with Valve VR in mind would be a big selling point.http://www.theverge.com/2013/11/19/51212...r-steam-support

Indeed, the Valve VR solution sounds very promising (pretty much like everything Valve did in this year. Now they just need to release Half Life 3).

Anyways, from a developers standpoint, this is pretty much zero news right now. There is no SDK or actual hardware to work against, and especially something like a VR device should be tested with actual hardware. We are lucky in this regard because Nils has an Oculus Rift (and had it pretty much from the first day), so it was "kind of" easy to integrate into Rayne.
Let's see what the future brings though, I can't say anything definite right now, but let's see what they unveil in January.

Also, anyone want to hear a funny story? I lost the passphrase to my SSH keys and can't access the Rayne server nor any of the git repositories. And I know that Nils made some really exciting commits yesterday. Tl;dr: Always make backups kids (and then make sure you can actually use the backup to restore your system)

Edit: Generated a new pair of SSH keys and regained access to the server. Have another Sponza picture made with the new lighting engine in place (written by Nils, so everyone say "thank you Nils for putting your time into nice lights")

Since you regained access story is not funny anymore. I was like
HAHAHAHAHAHAHahahhaa hhmmm...

For the screenshot, I especially like the white pixels dancing on that poles. What are they?

You can read the previous sentence as "WHERE IS MY ANTIALIASING?"

Geez, you guys are a hard to please crowd. What's next? An actual release?!

But yeah, truth be told, not anti-aliasing support for now (and not because I can neither spell nor pronounce that word). The reason is that we use a pretty non standard approach when it comes to compositing the final image that's rendered on the screen. On the one hand that means that it's incredible easy to support colour correction shaders and colour blind modes (which you should! Seriously, people should take accessibility support way more serious), but on the other hand it means that things like anti-aliasing are harder.

It's not impossible, it just isn't in the rendering pipeline yet because, well, what can I say, we are lazy fucks.


But since it's saturday, and that means it's screenshot saturday, here is a collection of old screenshots. Starting with the ones we took after fucking up the rendering:

Also, since saturday is basically the same as throwback thursday, here are the first ever made screenshots of Sponza (for a bug report with Apple because the gamma correction broke when rendering in certain ways. Nowadays we do gamma correction ourselves. Suck it, Apple!):


(Age: 9 months. You could literally have had a child in the time we took to increase texture quality and add lights into that level)

And last but not least, one of the very first actual screenshots ever made!


(Showing of the first incarnation of the post processing chain)

And last but not least, the very, very first screenshot ever made!

(Fun fact, the texture was loaded using a custom WebKit that rendered a hand made HTML page into a CoreGraphics context that was then loaded into OpenGL, because for some reason, I couldn't be arsed to write a texture loader)

Cool.

Thank you for subscribing to Rayne facts. Send "STOP" to continue!

We dug deeper into the screenshot stash, and we found MUCH more glitched rendering screenshots. We will continue with normal Rayne facts shortly, but for now we will have another round of Glitch facts!


This is the most boring one. Just a bit of broken SSAO


This one is wicked cool though! We used to render the scene with a depth pre-pass to minimize overdraw, however, the render chain was set up in a way that the character would move, drag the camera with it and the camera would then render the scene with a slight offset resulting in some fragments not passing the depth test.


Completely messed up particle rendering. The reason was that the particle emitter allocates a large enough VBO to hold the maximum number of particles, but only uses the first n entries of it for the active particles. The renderer didn't care about that and just rendered everything that was inside the VBO.


Something messed up the order of the upper half polygon that is used to composite the final image, resulting in this gradient bleeding into the image.

And now back to Rayne facts!
Fact #1: The first sprite rendered in Rayne was the Unity3d logo. We are easily entertained by ourselves.