DEV Community: nongyi531415

Designing a free text preview inside a paid AI video workflow

nongyi531415 — Tue, 27 Oct 2026 05:50:58 +0000

A free text preview inside a paid media workflow creates a very specific UI problem: what, exactly, has the user approved?

I am the maker of AI Rap Videos, where a person or pet photo becomes a short rap performance. The public flow lets people preview and edit four English lyric lines before purchasing a video. That gives a concrete example for the design pattern below. This is a suggested frontend model, not a description of our private backend or a claim about conversion results.

Separate three promises

A lyric preview shows the words. It does not preview the final voice, timing, facial motion or complete video. A price quote describes a purchase. A generation result proves that a file exists.

Those three promises should have different labels and states. A single boolean such as isReady cannot tell a component which promise it is making.

Make stale previews visible

Consider this sequence:

A user requests a birthday verse for Alex.
The user changes the name to Sam before the response arrives.
The older request returns with Alex's lyrics.

If the UI simply renders the last response to finish, it can show an apparently successful preview for the wrong input. Disabling the button alone does not solve requests already in flight.

A minimal illustrative TypeScript model can attach a local revision to requests:

type PreviewState =
  | { status: 'idle' }
  | { status: 'loading'; revision: number }
  | { status: 'ready'; revision: number; text: string }
  | { status: 'error'; revision: number; message: string };

function acceptPreview(
  currentRevision: number,
  responseRevision: number,
  text: string,
): PreviewState | null {
  if (responseRevision !== currentRevision) return null;
  return { status: 'ready', revision: responseRevision, text };
}

The caller should ignore a null result, not replace the current screen with it. Increment the revision when preview-relevant inputs change. Cancellation can reduce wasted work, but the revision check still matters if cancellation arrives too late. This is a UI consistency mechanism; it is not authorization for a paid job.

Treat editing as ownership

Once a person edits the verse, an automatic refresh should not silently replace it. Keep the editable draft distinct from a proposed replacement, and let the person choose whether to apply the new version. Preserve the draft after a recoverable failure.

Some settings affect the preview and others affect only the output. Define that boundary explicitly. Changing the subject name should invalidate a verse about the old name; changing portrait to landscape need not discard the person's writing if the text remains applicable.

Keep payment language precise

Use a label such as “Preview my lyrics · free” for the text step, and show the paid video price separately. On our public page, standard 480p and HD 720p also consume different amounts of video balance. A resolution change therefore needs a clear cost update even when the lyrics stay unchanged.

The server must independently check the final request, balance and applicable rules. A frontend ready state must never serve as payment proof.

Test the transitions, not just the happy path

Useful checks for this pattern include an old response arriving after a new one, edits made while a request is running, changing a cost-affecting option after preview, and retrying after a network error without losing the draft. Also check that keyboard focus and an accessible status message make loading and errors understandable.

These checks answer a narrower, testable question than “is the generator working?”: does the UI consistently show the text and price the user actually chose?

Disclosure: I make the linked product. This article was drafted with AI assistance and checked against the current public product flow; the code is an illustrative pattern, not production source.

Building a pet-only meme video page: what the sample needs to prove

nongyi531415 — Sun, 11 Oct 2026 14:28:23 +0000

I built Bulin47, a pet-only video project inspired by the Bulin 47 freestyle meme. The idea is deliberately narrow: use one authorized pet photo to replace the lead performer in a fixed clip, keeping the other people and the scene unchanged.

The output specification is about 19 seconds, vertical 9:16, 480p, with the original freestyle audio. The frontend uses TanStack Start, React and TypeScript, with Cloudflare Workers for deployment. The video-editing integration uses Seedance 2.5 through EvoLink.

A comparison is more useful than a polished thumbnail

A thumbnail can show the pet but hide whether the motion, timing and surrounding scene survived the edit. I put an original-versus-pet comparison alongside the input photo on the public page. That gives visitors three things to inspect: the source identity, the replaced performer, and the unchanged context.

For this kind of app, I would evaluate a sample along separate axes:

Does the pet remain recognizable throughout the clip?
Does the lead follow the reference movement and timing?
Do background people and objects stay consistent?
Does the exported file preserve the expected duration, orientation and audio?

One attractive frame cannot answer all four. A full clip and a visible input make the example easier to judge.

Keep the input boundary explicit

This project accepts pet photos only, without human faces or bodies. It is a useful constraint to communicate directly in the upload instructions instead of leaving it inside a policy page. The goal is pet entertainment, with a single fixed reference rather than an unrestricted face-swap interface.

Make the example match the copy

I also checked that the deployed sample assets matched the reviewed video files. A page can have correct copy while still serving an older sample. Keeping the input photo, comparison video and description aligned matters just as much as the framework choice.

You can inspect the Bulin47 sample comparison. I would welcome feedback on whether the comparison makes the intended edit clear.

This is an independent fan-made project, not affiliated with the artists or their labels. Results vary; the example is not a quality guarantee for every pet photo.

I built an AI pet dance app: one photo, one generator

nongyi531415 — Sat, 10 Oct 2026 13:25:30 +0000

I built CatDance, a small web app that turns a pet photo into an AI dance video. The idea is playful: take a cat, dog or plush photo and make it the star of a short dance clip.

Update — October 23, 2026: CatDance now offers a NEON cat dance template alongside Smalltown Boy. Personalized generation is paid; the earlier free-preview offer described at launch has ended.

One photo, two dance templates

For NEON, upload a clear cat photo to replace the lead dancer in the routine to A2O LITE’s NEON. Add a second pet photo, reuse the same photo for both dancers, or leave B empty to keep the default tuxedo cat. The scene is fixed. New videos are approximately 10 seconds, 720p and landscape 16:9, with original template audio and no watermark. The white-cat demo is labeled 480p; it is not a paid 720p output example.

Smalltown Boy remains a separate template: about 19 seconds, 720p and portrait 9:16, with an optional second pet and preset backgrounds. Its background choices do not apply to NEON.

Both use one-time USD purchases: $9.90 for one generation or $29.90 for four. There is no subscription or free personalized generation. Confirmed failed generations restore the credit; completed AI results can vary in appearance and movement. Including original template audio does not grant additional music rights or a commercial-use license.

Generation is only half the job

The frontend uses React and TanStack Start, with the application running on Cloudflare Workers. Generated files are delivered through object storage.

One practical lesson: a provider reporting “completed” is not the same as a customer having a downloadable video. The application still has to retrieve the output, assemble the full clip when necessary, attach template audio and persist the final file.

I now treat delivery as an explicit part of the job lifecycle. Errors record which stage failed, retries have a limit, and failed orders return the generation credit. An ambiguous submission should also be investigated before automatically submitting the same paid model request again.

Show the output before asking for a purchase

The homepage includes real input-photo and video examples. For a creative tool, those pairs explain the product better than a long feature list: people can judge whether the result is something they would want to share.

Photo quality and subject identity still matter. A clear image with one visible subject is a better starting point than a crowded or heavily cropped photo. Two-pet replacement is a more demanding task than replacing a single pet, and AI results can vary.

Try it

You can see the examples and use the generator at catdance.app. I am the maker of the product; this is a launch note, not an independent review.

For the new routine, start with the NEON examples and generator. I would be interested in feedback on whether the template examples and upload flow make the choices clear.

Why nuke simulators show different numbers (and how to compare them)

nongyi531415 — Fri, 02 Oct 2026 14:37:02 +0000

After I posted a short video of a simulated 15 kiloton airburst, a viewer commented that they had checked another calculator and got different numbers. That is a fair point, and the answer is not that one tool is broken. Blast simulators make different modelling choices, and those choices move the rings a lot.

I build Kaboomly, a free nuke map that runs in the browser, so here are the four choices that matter most.

1. Airburst or surface burst

The same weapon behaves very differently depending on where it goes off. An airburst spreads the blast wave over a wider area, so the light-damage rings get bigger. A surface burst gives smaller blast rings but pulls soil into the fireball and creates local fallout. Some tools default to one, some to the other.

2. Burst height

Even among airbursts, height matters. There is a height that maximizes the area of a given overpressure, and it is different for every pressure level. Kaboomly does not optimize this. It takes one documented historical example, Hiroshima at about 1,670 ft for roughly 12.5 kt, and scales it with the cube root of the yield. A tool that picks a different height will show different rings for the same yield.

3. Which threshold a ring represents

A ring labelled "heavy damage" might be drawn at 5 psi in one tool and at 10 or 20 psi in another. Thermal rings can mean first, second or third-degree burns, and the distance changes a lot between them. Always check the legend before comparing two maps.

4. Scaling law and source data

Most public calculators, including NUKEMAP and Kaboomly, trace back to The Effects of Nuclear Weapons by Glasstone and Dolan (1977). Blast distances scale with the cube root of yield, so ten times the yield gives only about 2.15 times the distance. The fireball has its own scaling, about W^0.4. Tools that use rounded rules of thumb instead of the published curves will drift, especially at very small or very large yields.

An example

For a 15 kt airburst Kaboomly shows the 5 psi ring at about 1.6 km (1.0 mi) and the 1 psi ring at about 4.5 km (2.8 mi). If another tool uses a surface burst or a different height, its numbers for the same yield can be noticeably smaller or larger, and both can be correct for their own assumptions.

What I did about it

On Kaboomly every result shows the burst type and the thresholds, and there is a page explaining how the numbers are calculated with references. The site never shows casualty estimates, only the rings and the number of residents living inside an area.

If you compare simulators, compare like with like: same yield, same burst type, same threshold. The differences mostly disappear.

Splitting a large image across multiple printed pages without alignment marks

nongyi531415 — Fri, 18 Sep 2026 00:46:00 +0000

I recently added tiled printing to a small static tool I run (ArtGrid) — the kind of "print a big image across several A4 sheets and tape them together" feature you've probably seen in poster-printing tools. The naive version is easy: slice the enlarged image into a grid of page-sized rectangles, export each as a PDF page. The annoying version is making the pieces line back up on paper, where a fraction of a millimeter of printer scaling error compounds across every seam.

Most tools solve this with alignment marks — corner crosses or registration dots you have to trim to and match by eye. I skipped that entirely by changing where the cuts land.

The trick: cut on lines that are already there

My tool overlays a grid on the reference image — rows and columns of equal square cells, used for the classic grid-method drawing technique. Once you're enlarging that grid to poster size, you already have a full set of straight lines running across the whole surface. If every page boundary is forced to land exactly on one of those grid lines, the seam is the line. There's nothing to trim, because the join is a continuation of a mark you were going to draw anyway.

The constraint this puts on the math: instead of dividing by fixed page dimensions, you divide by however many whole cells fit on a page, and let the last row/column of pages be a partial page if it doesn't divide evenly.

function tileGeometry(geometry: GridGeometry): TileResult {
  const area = tileArea(geometry.paper); // printable area minus margins
  const { drawingCell, columns, rows } = geometry;

  if (drawingCell > area.w || drawingCell > area.h) {
    return { ok: false, error: `cell ${drawingCell}mm exceeds printable area` };
  }

  const colsPerPage = Math.floor(area.w / drawingCell);
  const rowsPerPage = Math.floor(area.h / drawingCell);
  const pagesX = Math.ceil(columns / colsPerPage);
  const pagesY = Math.ceil(rows / rowsPerPage);

  return { ok: true, value: { colsPerPage, rowsPerPage, pagesX, pagesY,
    pageCount: pagesX * pagesY } };
}

Each page then covers a [colStart, colEnd) × [rowStart, rowEnd) slice of cells, and the pixel crop for that page is just that slice's bounding box in the source image, scaled the same way the whole grid was scaled. Cutting on floor(printable_area / cell_size) rather than on the raw page dimension is the entire trick — it's a one-line change from "divide by page size" that removes a whole category of physical-alignment UX.

Why this only works if the cells are square

This only holds together because every cell is guaranteed to be the same width and height. If rows and columns are sized independently — which most grid tools do, because it lets you fill the page edge-to-edge — a "cell" isn't a fixed unit you can tile against, and you're back to needing marks. Forcing square cells (deriving whichever axis you didn't set, rather than letting both float to fill the sheet) was originally a decision about drawing accuracy — a square cell's diagonal is a clean 45°, useful for judging angles by eye — but it turned out to be the same property that makes tiling trivial later. One geometric constraint paid for two unrelated features.

Testing the seams

The part I actually didn't trust until I checked it: does the printable rectangle reconstructed from all the tiles equal the original enlarged rectangle, to the millimeter? I wrote this as a standalone assertion rather than trusting the math by inspection:

const topRowWidth = pages.filter(p => p.rowStart === 0)
  .reduce((sum, p) => sum + p.tileRectMm.w, 0);
console.assert(Math.abs(topRowWidth - drawingRect.w) < 0.01);

— summed the top row's page widths, summed the left column's page heights, compared both against the target enlargement size. It matched to a hundredth of a millimeter, which is the point where you stop worrying about floating point and start worrying about your actual printer's calibration instead (which is why there's still a 50mm ruler printed on the first page — measure it, and if your printer scaled the page, you'll catch it before taping together nine sheets).

If you want to see the live version: griddrawing.org/print-large-image-multiple-pages. It's a static site, runs entirely client-side, source reference stays in the browser tab.