Before you submit
What happened?
Hey, I don't know if it's just me or something's wrong. I am on the latest version of Open Design, and I've noticed that, since version 0.6 probably, things have seemed to have gone downhill.
While the interface looks better and the template selection is better, the feature list seems to have grown. The quality of the output and the amount of tokens that Open Design uses across tools (by the way, whether it's Codex or Claude or Gemini) and the length of time it takes to create a design is crazy long. The output seems to be awful. I do better work with my regular Codex or Claude subscriptions.
I asked Open Design to render me a promo video for app screens. It seems to have used HyperFrames and maybe one or two other tools. It generated me three unusable files, which were literally a single image in a video. It didn't even have an app screen or mobile information or anything.
I'm quite disappointed in the output quality, and I don't really know what to do, because it took hours, realistically, of back and forth. Every time it is building me bad videos that don't actually do anything and aren't an app promo. This should be a basic feature of Open Design, considering the fact that tools like HyperFrames, ReMotion, et cetera allow for you to create promo videos for apps or platforms or websites in a very simple and easy-to-use way. I don't understand why this isn't doing it properly.
Steps to reproduce
You’re right to call that out. I’m going to treat the renders as failed outputs, inspect the existing compositions and the generated video behavior, then fix only what’s causing blank frames before rerendering a single test variation.I’m using the HyperFrames guidance because the problem is now specific to HTML video composition rendering, not media prompting. I’ll keep this scoped to the existing three Daas-1 compositions.The rendered files exist but that doesn’t mean they’re usable. I’m checking the composition contract and the authored DOM next; a blank render usually comes from clips not being discoverable by the renderer, content being hidden at capture time, or animation state not being seekable.I found the first concrete issue: the entry file references ../shared/daas1-core.js, not the filename I initially probed. I’m reading that shared runtime now and checking whether it ever populates #root; if it doesn’t, the render would be a perfectly valid blank page.The shared script does populate the root, so the blank result likely comes from HyperFrames not treating the root/content as a clip or from the renderer seeking a timeline that never initializes under its capture environment. I’m checking the minimal required markup before patching.The issue is now clear enough to patch: the scenes are inserted as plain .scene divs, but HyperFrames expects visible timed elements to be direct child clips with class="clip" plus timing attributes. I’m going to add proper clip timing and move the full-frame background onto a child element so captured frames have real paint behind the scenes.I’m editing the shared files only, because all three variations use the same renderer/runtime. That gives us one fix for command-center, donor-journey, and outreach-engine instead of patching each composition separately.
The shared patch is in. I’m running the lightweight HyperFrames checks on the first composition now; if those pass, I’ll render one MP4 and inspect actual frame pixels before spending time on the other two.The checks exposed a second concrete cause: the shared CSS/JS paths validate as 404s under the project server. I’m changing the three entry files to root-relative project paths so the renderer and validator load the same shared files consistently.
The entry paths are fixed. I’m validating again, then I’ll render only command-center and sample its frames before touching the other two outputs.inspect is now clean, but validate serves each composition directory as its own root. The shared files need to live inside each composition folder for the renderer’s server model, so I’m copying the shared runtime locally into each variation and pointing the entries at shared/....The runtime files are now local to each composition. I’m rerunning validation on command-center and then rendering a fresh file over the old blank one if the runtime loads correctly.Validation now loads the runtime. There are layout warnings from overlapping decorative cards, but they are not blank-screen failures. I’m rendering command-center again and will sample actual frames from the MP4 before continuing.The dispatcher queued a render task, but PowerShell treated the progress line on stderr as an exception. I’m polling that task directly instead of starting a duplicate render.Command-center rendered again. The new file is much smaller than the old blank exports, so I’m extracting a few frames and checking actual pixels visually before I call this fixed.The command-center frame is still blank after the clip/path fix, so I’m not going to render the other two yet. The remaining likely problem is that the renderer’s static contract does not recognize the timeline because it is registered in an external shared script; I’m moving the render-critical runtime inline/static for one variation first.
I’ll test the smallest plausible fix first: add a local timeline registration in the entry file before the shared script runs. The shared script can still replace it with the full animation, but the renderer will see a valid composition contract in the entry itself.
I’m rerendering the single command-center test again. If this still produces dark frames, I’ll stop trying incremental fixes and convert the composition to static authored HTML instead of runtime-generated DOM.The inline registry did not change the output size, so I’m checking one frame quickly. If it is still blank, I’ll replace the runtime-generated DOM approach with static DOM in the composition.The frame is still the same tiny dark PNG, so the dynamic-render path is the wrong shape for this renderer. I’m converting the compositions to static HTML now, generated from the existing variant data, with the same styling and animation intent.
I’m generating static index.html files from the existing variant data, not redesigning them. The important change is that every visible scene will exist in the HTML before the renderer scans the composition, instead of being inserted later by JavaScript.The three entry files now contain static scene markup. I’m changing the scene CSS so active clips are visible by default; the timeline adds motion, but visibility no longer depends on JavaScript opacity setup.I caught a PowerShell escaping mistake in the CSS replacement: it inserted literal backtick text instead of a real newline. I’m correcting that before running any render.The CSS is corrected. I’m validating the static command-center composition now; then I’ll render and visually sample frames again.The static version loads, and validation sees real text now. Lint found two contract issues I’m fixing before render: the root needs data-start="0", and the CSS named fonts the renderer cannot guarantee.Those contract fixes are in across all three compositions. I’m rerunning the command-center gates and then the single render test.The gates now pass with only non-blocking structure warnings. I’m rendering command-center again; this time I expect a much larger file if real UI frames are being captured.That fixed the blank render: command-center is now 4.3 MB instead of 90 KB. I’m extracting and checking sample frames so I don’t ship an overlaid or empty video.The sampled frame is now real UI, not blank. I’m checking the mid and final samples for scene progression before rendering the remaining two.
The middle scene is also real and readable. I’m checking the ending frame, then I’ll render donor-journey and outreach-engine with the same static fix.
Command-center is fixed and visually verified across three points. I’m rendering donor-journey and outreach-engine now from the patched static compositions, then I’ll sample their frames too.Both remaining renders completed with multi-megabyte outputs. I’m extracting verification frames and checking hashes/sizes so we know they’re not blank and not accidentally identical.The remaining two sample frames are large PNGs and the three MP4 hashes are now distinct. I’m visually checking one donor and one outreach frame, then I’ll update the project status.
Donor-journey is visibly rendered. I’m checking outreach now, then I’ll update critique.json with the corrected status and verification notes.
Outreach is no longer blank, but the first-frame headline is too tall and pushes the lede near the bottom edge. I’m tightening only the outreach composition’s first-scene type scale and rerendering that one so the three outputs are actually usable, not merely nonblank.
I’m rerendering only outreach-engine now, then I’ll resample its opening frame.The rerender attempt for the tightened outreach version was rejected by the Open Design daemon with TOOL_TOKEN_INVALID. I still have two fully verified fixed videos and one nonblank outreach render; I’m recording the current state so we don’t hide that the final outreach tightening could not be exported in this run.The old critique file still says the blank identical outputs were successful, so I’m replacing that verification section with the current truth: static composition fix, two clean verified outputs, outreach nonblank but final tightened rerender blocked by a revoked tool token.The status update mostly landed, but PowerShell refused to add a new JSON property using dot assignment. I’m adding that field correctly and rechecking the JSON parse.
Expected behavior
in 5-10 mins it should render me a clean promo video...
Open Design version
0.12.0
Platform
Windows
Logs (optional)
Screenshots (optional)
No response
Additional context
No response
Before you submit
od --version.What happened?
Hey, I don't know if it's just me or something's wrong. I am on the latest version of Open Design, and I've noticed that, since version 0.6 probably, things have seemed to have gone downhill.
While the interface looks better and the template selection is better, the feature list seems to have grown. The quality of the output and the amount of tokens that Open Design uses across tools (by the way, whether it's Codex or Claude or Gemini) and the length of time it takes to create a design is crazy long. The output seems to be awful. I do better work with my regular Codex or Claude subscriptions.
I asked Open Design to render me a promo video for app screens. It seems to have used HyperFrames and maybe one or two other tools. It generated me three unusable files, which were literally a single image in a video. It didn't even have an app screen or mobile information or anything.
I'm quite disappointed in the output quality, and I don't really know what to do, because it took hours, realistically, of back and forth. Every time it is building me bad videos that don't actually do anything and aren't an app promo. This should be a basic feature of Open Design, considering the fact that tools like HyperFrames, ReMotion, et cetera allow for you to create promo videos for apps or platforms or websites in a very simple and easy-to-use way. I don't understand why this isn't doing it properly.
Steps to reproduce
You’re right to call that out. I’m going to treat the renders as failed outputs, inspect the existing compositions and the generated video behavior, then fix only what’s causing blank frames before rerendering a single test variation.I’m using the HyperFrames guidance because the problem is now specific to HTML video composition rendering, not media prompting. I’ll keep this scoped to the existing three Daas-1 compositions.The rendered files exist but that doesn’t mean they’re usable. I’m checking the composition contract and the authored DOM next; a blank render usually comes from clips not being discoverable by the renderer, content being hidden at capture time, or animation state not being seekable.I found the first concrete issue: the entry file references
../shared/daas1-core.js, not the filename I initially probed. I’m reading that shared runtime now and checking whether it ever populates#root; if it doesn’t, the render would be a perfectly valid blank page.The shared script does populate the root, so the blank result likely comes from HyperFrames not treating the root/content as a clip or from the renderer seeking a timeline that never initializes under its capture environment. I’m checking the minimal required markup before patching.The issue is now clear enough to patch: the scenes are inserted as plain.scenedivs, but HyperFrames expects visible timed elements to be direct child clips withclass="clip"plus timing attributes. I’m going to add proper clip timing and move the full-frame background onto a child element so captured frames have real paint behind the scenes.I’m editing the shared files only, because all three variations use the same renderer/runtime. That gives us one fix for command-center, donor-journey, and outreach-engine instead of patching each composition separately.The shared patch is in. I’m running the lightweight HyperFrames checks on the first composition now; if those pass, I’ll render one MP4 and inspect actual frame pixels before spending time on the other two.The checks exposed a second concrete cause: the shared CSS/JS paths validate as 404s under the project server. I’m changing the three entry files to root-relative project paths so the renderer and validator load the same shared files consistently.
The entry paths are fixed. I’m validating again, then I’ll render only command-center and sample its frames before touching the other two outputs.
inspectis now clean, butvalidateserves each composition directory as its own root. The shared files need to live inside each composition folder for the renderer’s server model, so I’m copying the shared runtime locally into each variation and pointing the entries atshared/....The runtime files are now local to each composition. I’m rerunning validation on command-center and then rendering a fresh file over the old blank one if the runtime loads correctly.Validation now loads the runtime. There are layout warnings from overlapping decorative cards, but they are not blank-screen failures. I’m rendering command-center again and will sample actual frames from the MP4 before continuing.The dispatcher queued a render task, but PowerShell treated the progress line on stderr as an exception. I’m polling that task directly instead of starting a duplicate render.Command-center rendered again. The new file is much smaller than the old blank exports, so I’m extracting a few frames and checking actual pixels visually before I call this fixed.The command-center frame is still blank after the clip/path fix, so I’m not going to render the other two yet. The remaining likely problem is that the renderer’s static contract does not recognize the timeline because it is registered in an external shared script; I’m moving the render-critical runtime inline/static for one variation first.I’ll test the smallest plausible fix first: add a local timeline registration in the entry file before the shared script runs. The shared script can still replace it with the full animation, but the renderer will see a valid composition contract in the entry itself.
I’m rerendering the single command-center test again. If this still produces dark frames, I’ll stop trying incremental fixes and convert the composition to static authored HTML instead of runtime-generated DOM.The inline registry did not change the output size, so I’m checking one frame quickly. If it is still blank, I’ll replace the runtime-generated DOM approach with static DOM in the composition.The frame is still the same tiny dark PNG, so the dynamic-render path is the wrong shape for this renderer. I’m converting the compositions to static HTML now, generated from the existing variant data, with the same styling and animation intent.
I’m generating static
index.htmlfiles from the existing variant data, not redesigning them. The important change is that every visible scene will exist in the HTML before the renderer scans the composition, instead of being inserted later by JavaScript.The three entry files now contain static scene markup. I’m changing the scene CSS so active clips are visible by default; the timeline adds motion, but visibility no longer depends on JavaScript opacity setup.I caught a PowerShell escaping mistake in the CSS replacement: it inserted literal backtick text instead of a real newline. I’m correcting that before running any render.The CSS is corrected. I’m validating the static command-center composition now; then I’ll render and visually sample frames again.The static version loads, and validation sees real text now. Lint found two contract issues I’m fixing before render: the root needsdata-start="0", and the CSS named fonts the renderer cannot guarantee.Those contract fixes are in across all three compositions. I’m rerunning the command-center gates and then the single render test.The gates now pass with only non-blocking structure warnings. I’m rendering command-center again; this time I expect a much larger file if real UI frames are being captured.That fixed the blank render: command-center is now 4.3 MB instead of 90 KB. I’m extracting and checking sample frames so I don’t ship an overlaid or empty video.The sampled frame is now real UI, not blank. I’m checking the mid and final samples for scene progression before rendering the remaining two.The middle scene is also real and readable. I’m checking the ending frame, then I’ll render donor-journey and outreach-engine with the same static fix.
Command-center is fixed and visually verified across three points. I’m rendering donor-journey and outreach-engine now from the patched static compositions, then I’ll sample their frames too.Both remaining renders completed with multi-megabyte outputs. I’m extracting verification frames and checking hashes/sizes so we know they’re not blank and not accidentally identical.The remaining two sample frames are large PNGs and the three MP4 hashes are now distinct. I’m visually checking one donor and one outreach frame, then I’ll update the project status.
Donor-journey is visibly rendered. I’m checking outreach now, then I’ll update
critique.jsonwith the corrected status and verification notes.Outreach is no longer blank, but the first-frame headline is too tall and pushes the lede near the bottom edge. I’m tightening only the outreach composition’s first-scene type scale and rerendering that one so the three outputs are actually usable, not merely nonblank.
I’m rerendering only outreach-engine now, then I’ll resample its opening frame.The rerender attempt for the tightened outreach version was rejected by the Open Design daemon with
TOOL_TOKEN_INVALID. I still have two fully verified fixed videos and one nonblank outreach render; I’m recording the current state so we don’t hide that the final outreach tightening could not be exported in this run.The old critique file still says the blank identical outputs were successful, so I’m replacing that verification section with the current truth: static composition fix, two clean verified outputs, outreach nonblank but final tightened rerender blocked by a revoked tool token.The status update mostly landed, but PowerShell refused to add a new JSON property using dot assignment. I’m adding that field correctly and rechecking the JSON parse.Expected behavior
in 5-10 mins it should render me a clean promo video...
Open Design version
0.12.0
Platform
Windows
Logs (optional)
Screenshots (optional)
No response
Additional context
No response