ReyEngine v0.4.8-beta

A release about a map with everything switched on, and about getting a shot out of it. The viewport stopped redoing work it had already done and stopped doing a toggle's worth of loading inside one frame, and it now says where a frame's time went instead of leaving you to guess. Cinematic Capture keeps the sky it was framed with, and a captured sequence runs at the speed of the shot rather than the speed of the export.

Improved

• A map with particles, animated props and lights repeats less work every frame. Four things the viewport was redoing sixty times a second now happen once. A particle emitter that carries an animated mesh was re-posed by a call that builds a pose buffer, a positions array, a normals array, a bone-segment array and a table of every joint name in the skeleton — and then used the positions alone; it now poses into buffers it keeps, and skips the normals the mesh pipeline never reads. The same normals were being computed and dropped for animated props on their fallback path. The rings that show how far each light reaches were re-uploaded to the graphics card every frame even when no light had moved, which on the Harrowing map's 676 lights is about 2.3 MB a frame; they are uploaded when they change now, like the light markers beside them. And a placed prop's mesh was decoded twice — once in the background where it belongs, then again on the frame's own thread as the props were handed to the viewport — so switching props on paid for every prop mesh a second time.
• An effect fills its first moment without reallocating on every frame of it. Each emitter keeps the particles it has drawn in one array, and that array was resized to exactly what was needed — so an emitter gaining a particle a frame, which is every emitter while it fills, replaced the whole array each time, and a system being warmed for the camera does that up to 150 times. The array grows in steps now: warming the jade map's 425 systems allocates 29.5 MB instead of 37.5 MB.
• Switching props on no longer stops the frame. Every distinct prop mesh was uploaded in one go - the shaders resolved, every texture decoded, the pipeline built and the geometry sent to the graphics card - and it happened inside the frame the viewport was drawing, because that is where the viewport is handed the prop set. On a map with twenty-eight different props that is twenty-eight meshes' worth of loading between two frames, every time props are switched on and on every scene rebuild. The meshes now arrive a few per frame under a time budget, the way a particle system entering the camera is warmed, so the props fill in over a handful of frames instead of the editor stopping for all of them. The viewport's frame line says how many are still to come.
• The viewport says where the particle time goes. The frame line reported the particle step as a single number, which tells you the particles are expensive without telling you which part of them is - and the parts have nothing in common: the camera gate, the simulation itself, the mesh and ribbon emitters, turning live particles into vertices, and sending those to the graphics card are five different costs with five different fixes. Each is timed and named on the line under the frame time, and the one-off rebuild after a playback change is separated from the work every frame does.

Fixed

• Capturing a sequence dropped the sky out of the map. The cinematic capture saves its settings before the first frame and writes a PNG per frame, and the editor watches the project folder so files added from outside show up on their own. That refresh rebuilt the skybox list, and rebuilding the list reset it to "No skybox" - so a second into a capture the sky vanished from the viewport and every frame after it was written without one. The chosen sky is kept now: a refresh that finds the same skyboxes leaves the selection alone entirely, and one that finds a different set restores the same sky by name, without re-loading it. Saving a bin or adding a mesh dropped the sky the same way, and no longer does; the preview window's own sky list had the same fault.
• A captured sequence ran its effects fast and its props slow. The viewport keeps drawing while a capture runs, on purpose, so you can watch the shot go by - but those live frames are on the wall clock while the captured ones walk the shot's timeline, and both were writing to the same two pieces of state. Every live frame that landed between two captured ones handed the particles a step of "now minus the shot's time", which the simulator caps at a tenth of a second and then applies: at 60 frames a second the effects advanced about six times too fast. The same crossing left the props' last-posed time on the other clock, so two captured frames in a row hit the rate limit meant for live frames and the second one repeated the first one's pose, which is why the props came out slow. A captured frame now steps by the gap to the previous captured frame and poses every prop every time - an export has no frame budget to spend - and a live frame drawn during a capture shows the shot without moving anything.