first commit

This commit is contained in:
2026-06-11 03:33:14 +08:00
commit 5f555bf342
599 changed files with 142347 additions and 0 deletions

View File

@@ -0,0 +1,66 @@
# `nature-writing` skill
A Nature-style manuscript writing skill for drafting or rebuilding sections from
author-provided claims, figures, results, notes, or Chinese drafts.
## What it does
`nature-writing` helps write:
- titles
- abstracts
- introductions
- results narratives
- discussions
- conclusions
- significance paragraphs
- manuscript outlines
It is for argument construction and section drafting. For sentence-level polish
of an existing draft, use `nature-polishing`.
## Built from
Close reading of curated Nature and Nature Communications research articles
across materials, energy systems, construction decarbonization and machine
learning, combined with the existing writing-strategy rules in this repository.
Section-level writing and reviewer-facing self-review guidance is also adapted
from Prof. Peng Sida's open research-writing notes:
- https://pengsida.notion.site/c1a22465a0fa4b15a12985223916048e
- https://github.com/pengsida/learning_research
## File structure
```text
nature-writing/
├── README.md
├── SKILL.md
└── references/
├── abstract.md
├── article-architecture.md
├── chinese-author-workflow.md
├── conclusion.md
├── experiments.md
├── introduction.md
├── method.md
├── paper-review.md
├── paragraph-flow.md
├── related-work.md
└── examples/
```
## Key rules
| Domain | Core rule |
|---|---|
| Evidence first | Do not invent data, mechanisms, statistics, sample sizes or novelty |
| Abstract | Context, gap, approach, key result, implication, boundary |
| Introduction | Field scale, bottleneck, prior attempts, unresolved gap, present study |
| Method | Explain module motivation, design, forward process, and technical advantage |
| Results | Build an evidence ladder, not a chronological lab diary |
| Experiments | Tie every major claim to comparison, ablation, metric, or stress-test evidence |
| Discussion | Explain meaning, prior-work relation, constraints and future use |
| Review | Run adversarial self-review before submission |
| Chinese notes | Translate intent and argument, not clause order |

View File

@@ -0,0 +1,159 @@
---
name: nature-writing
description: Draft, restructure, or plan Nature-style manuscript sections from author-provided claims, results, figures, notes, or Chinese drafts. Use when the user wants to write or rebuild an abstract, introduction, results narrative, discussion, conclusion, title, or full manuscript argument rather than only polish finished prose.
version: 0.2.0
author: Community contribution based on curated Nature/Nature Communications writing patterns and open research-writing notes
---
# Nature-Style Scientific Writing
Use this skill when the user needs help creating or rebuilding manuscript prose,
not merely polishing existing sentences.
## Core stance
- Author evidence comes first. Do not invent results, mechanisms, references,
methods, novelty, sample sizes, statistics or limitations.
- Write the argument before writing the sentences.
- Make the paper easy to judge: relevance, novelty, trust, reuse and meaning.
- Use ambitious but bounded claims.
- If essential evidence is missing, write a placeholder or ask for the missing
input instead of filling the gap.
## When to open extra files
| File | Open when |
|---|---|
| [references/article-architecture.md](references/article-architecture.md) | You need section-level structure, argument order, or published-article writing patterns |
| [references/abstract.md](references/abstract.md) | Drafting or revising an abstract, especially challenge-contribution and challenge-insight-contribution forms |
| [references/introduction.md](references/introduction.md) | Drafting or revising an Introduction, task framing, technical challenge, contribution framing, or teaser/pipeline logic |
| [references/related-work.md](references/related-work.md) | Rebuilding Related Work as topic synthesis instead of a paper-by-paper list |
| [references/method.md](references/method.md) | Writing Method sections, pipeline modules, module motivation, technical advantages, or implementation details |
| [references/experiments.md](references/experiments.md) | Planning or writing Experiments/Results around baselines, ablations, metrics, tables, figures, and claim support |
| [references/conclusion.md](references/conclusion.md) | Writing a bounded conclusion with contribution, evidence, impact, limitation, and future direction |
| [references/paragraph-flow.md](references/paragraph-flow.md) | User asks whether a paragraph flows, makes sense, or is clear; use reverse outlining and paragraph-message checks |
| [references/paper-review.md](references/paper-review.md) | Final manuscript self-review, rejection-risk audit, claim-evidence alignment, or reviewer-facing critique |
| [references/chinese-author-workflow.md](references/chinese-author-workflow.md) | The user's notes are Chinese, mixed Chinese-English, or organized as lab notes rather than manuscript prose |
| [references/examples/index.md](references/examples/index.md) | You need concrete abstract, introduction, or method examples after choosing the relevant guide |
## Intake
Before drafting, identify:
- manuscript section: title, abstract, introduction, results, discussion,
conclusion, significance paragraph or full outline
- paper type: mechanism, method, resource, device, model, clinical, materials,
computational or interdisciplinary
- core claim: what the paper actually demonstrates
- evidence: figures, measurements, comparisons, datasets, statistics or examples
- boundary: where the claim stops
- target journal or word limit, if provided
If any of `core claim`, `evidence` or `boundary` is absent, expose the gap before
drafting. You may still produce a scaffold with explicit placeholders.
## Writing workflow
1. Build a one-sentence argument: `In [system/problem], we show [advance] using
[approach], supported by [evidence], with [boundary].`
2. Choose the section architecture from `references/article-architecture.md`.
3. Map each paragraph to one job: context, gap, approach, result, comparison,
mechanism, implication or limitation.
4. Draft from evidence outward. Keep claims near the data that support them.
5. Calibrate verbs: `show`, `demonstrate`, `suggest`, `indicate`, `enable`,
`may`, `could`.
6. Remove unsupported novelty and universal claims.
7. Run a paragraph-flow check: one paragraph, one message, with a clear first
sentence and explicit sentence-to-sentence relation.
8. Return prose plus concise notes on assumptions and missing inputs.
## Section defaults
### Abstract
Default Nature pattern:
`context/problem -> gap -> approach -> key result -> implication -> boundary`
For technical AI, ML, CV or method-heavy manuscripts, open
`references/abstract.md` and choose one of:
- `challenge -> contribution`
- `challenge -> insight -> contribution`
- `multiple contributions`
Keep it compact. Include quantitative or comparative detail when the user
provided it. End with what the work enables, not generic importance.
### Introduction
Use:
`field scale -> bottleneck -> prior attempts -> unresolved gap -> present study`
For method-heavy papers, open `references/introduction.md` and reason backward
from the technical challenge and contribution before drafting forward.
Do not summarize all results. The final paragraph should state what this paper
does and how it addresses the gap.
### Results narrative
Use an evidence ladder:
`system/workflow -> validation -> main result -> baseline comparison ->
mechanism/diagnostic analysis -> application or generalization`
Each subsection should have a claim-first opening and then data support.
For ML/conference-style experiment sections, open `references/experiments.md`
and make sure each major claim is backed by comparison, ablation, or stress-test
evidence.
### Related Work
Use:
`topic scope -> representative methods -> limitation tied to this paper ->
distinction`
Group prior work by technical topic and mechanism, not by publication year.
### Discussion
Use:
`central advance -> evidence meaning -> relation to prior work -> constraints ->
future use`
This is where interpretation and limitations belong. Do not repeat the Results
section figure by figure.
### Conclusion
Use:
`contribution -> decisive evidence -> implication -> boundary`
No new data. No unsupported promises.
### Title
Prefer concrete titles that combine:
`system/object + action/capability + application or consequence`
Avoid slogan titles, grant-style aims and overbroad field claims.
## Output format
Default output:
1. `Draft:` with the requested prose.
2. `Section outline:` with `3-7` compact bullets when the task involves a full section.
3. `Assumptions or missing inputs:` with only material issues.
4. `Claim-evidence map:` for major claims, using `Claim: ... | Evidence: ... | Status: supported/needs evidence`.
5. `Why this structure:` with `2-4` short bullets.
For Chinese author notes, provide polished English first, then brief Chinese
notes explaining major structural choices.

View File

@@ -0,0 +1,4 @@
interface:
display_name: "Nature Writing"
short_description: "Draft Nature-style manuscript sections"
default_prompt: "Help me turn my claims, results, figures, or Chinese notes into a Nature-style manuscript section with a clear argument and claim-evidence map."

View File

@@ -0,0 +1,102 @@
# Abstract Writing Guide
## Goal
Write a strong abstract by doing three things repeatedly:
1. Think through the abstract logic first.
2. Follow one template (Version 1/2/3 below).
3. Revise the abstract many times.
## Pre-Writing Questions (Important)
Answer these before writing:
1. What technical problem do we solve, and why is there no well-established solution? (important)
2. What is our technical contribution?
3. Why can our method work in essence?
4. What technical advantage and new insight do we provide? (important)
## Version 1: Challenge -> Contribution
Introduce the technical challenge, then use one to two sentences to present the technical contribution that solves the challenge.
### Structure
1. Task.
2. Technical challenge for previous methods.
3. One to two sentences introducing the technical contribution for solving the challenge.
4. Benefits of the technical contribution.
5. Experiment summary.
### Expert Notes
1. Discuss previous work around the technical challenge that we actually solve.
2. For the contribution sentence(s), usually mention the technical term/name only; do not explain every detailed step.
3. The technical term must be easy to understand; readers should not feel a jump.
4. This ability is very important for writing a good abstract.
Version 1 local cite:
1. `references/examples/abstract/template-a.md`
## Version 2: Challenge -> Insight -> Contribution
Introduce the technical challenge, then use one to two sentences to present the insight for solving the challenge, and then one sentence to present the technical contribution that implements this insight.
### Structure
1. Task.
2. Technical challenge for previous methods.
3. One sentence introducing the insight for solving the challenge.
4. One to two sentences introducing the technical contribution that implements the insight.
5. Benefits of technical novelty.
6. Experiment summary.
### Expert Notes
1. Discuss previous work around the technical challenge that we actually solve.
2. Introduce the insight in one clear sentence.
3. For the implementation sentence(s), usually mention the technical term/name only; do not explain every detailed step.
4. The technical term must be easy to understand; do not create a jump in reading.
5. This ability is very important for writing a good abstract.
Version 2 local cite:
1. `references/examples/abstract/template-b.md`
## Version 3: Multiple Contributions
Version 3: When there are multiple technical contributions, describe each contribution together with its technical advantage.
### Structure
1. Task.
2. If needed, one contrast sentence about prior methods.
3. Contribution sentence 1 + technical advantage.
4. Contribution sentence 2 + technical advantage.
5. Contribution sentence 3 + technical advantage.
6. Experiment summary.
### Expert Notes
1. When there are multiple technical contributions, describe each contribution together with its technical advantage.
2. The ability to express "contribution + advantage" in one sentence is very important for writing a good abstract.
Version 3 local cite:
1. `references/examples/abstract/template-c.md`
## Example Bank
1. `references/examples/abstract-examples.md`
2. `references/examples/abstract/template-a.md`
3. `references/examples/abstract/template-b.md`
4. `references/examples/abstract/template-c.md`
## Abstract Quality Checklist
1. Can a reader identify task, challenge, insight/contribution, and results in one pass?
2. Are all major claims supported by experiments?
3. Are technical names self-contained and readable?
4. Is there any sentence that mixes too many messages?

View File

@@ -0,0 +1,107 @@
# Article Architecture
Use this reference when writing or rebuilding manuscript sections. The patterns
come from curated Nature and Nature Communications examples across materials,
energy, construction decarbonization and machine learning. They are structural
patterns, not wording templates.
## Full-paper argument
A strong paper can usually be reduced to:
`field-scale need -> unresolved bottleneck -> proposed move -> decisive evidence
-> broader implication -> boundary`
Before drafting, force the user's material into this chain. If one link is
missing, mark it as missing rather than writing around it.
## Abstract
Recommended paragraph movement:
1. Field-scale context or problem.
2. Why current routes do not fully solve it.
3. What this paper introduces or demonstrates.
4. The strongest result, preferably with quantitative or comparative support.
5. The mechanism, workflow or practical consequence.
6. Bounded implication.
Useful diagnostics:
- If the abstract begins with `Here, we`, it may be missing context.
- If it ends with a broad promise, it may need scope control.
- If it contains no number, comparison or concrete test, it may feel ungrounded.
## Introduction
Use a controlled funnel:
1. Establish the field stake.
2. Explain the bottleneck in existing practice.
3. Treat prior work fairly and specifically.
4. Identify the remaining capability gap.
5. State the present study as a direct response to that gap.
Avoid:
- a literature list without a narrowing logic
- claiming novelty by dismissing prior work
- announcing results before the reader understands the question
## Results
Arrange Results as an evidence ladder:
1. system, workflow or design space overview
2. validation that the platform or assay is credible
3. primary performance or discovery result
4. fair comparison with baseline, standard practice or prior method
5. mechanism, diagnostic analysis or interpretability
6. scale-up, application, generalization or stress test
Subsection opening rule:
`To test [question], we [action].`
Then report the result and evidence. Keep interpretation short unless the
paragraph explicitly transitions toward Discussion.
## Discussion
Discussion should widen from finding to meaning:
1. central advance
2. why the evidence supports it
3. how it changes a workflow, design rule or conceptual boundary
4. how it relates to previous studies
5. what limits or dependencies remain
6. what future work is now plausible
Do not restate every figure. Select the evidence that changes interpretation.
## Conclusion
Use a compact four-part close:
1. This work demonstrates or establishes the main contribution.
2. The decisive evidence is named.
3. The broader implication is stated.
4. The boundary condition is clear.
Conclusions should not introduce new data, new citations or new mechanisms.
## Title
Good titles are concrete and searchable:
`system/object + capability/action + application/consequence`
Examples of title logic:
- material plus function
- method plus task
- process plus scale
- model plus data regime
Avoid vague prestige words such as `novel`, `advanced`, `powerful`, `green`,
`efficient` unless they are made concrete by the rest of the title.

View File

@@ -0,0 +1,42 @@
# Chinese Author Workflow
Use this reference when the user's input is Chinese, mixed Chinese-English, or
written as lab notes.
## Translate intent, not syntax
Chinese academic notes often place background, motivation, method and implication
in one long sentence. Before drafting English, split the note into:
- claim
- evidence
- condition
- comparison
- implication
- limitation
Then write English in the order required by the section, not in the order of the
Chinese sentence.
## Common repairs
| Chinese-draft pattern | Repair |
|---|---|
| Broad importance before a clear object | Name the system or problem earlier |
| Method list before research gap | Move the gap before the method |
| `显著提高/明显改善` without baseline | Add the comparator or soften the verb |
| `首次/创新性` without scope | Replace with a bounded novelty claim |
| Mechanism inferred from correlation | Use `suggests`, `is consistent with`, or ask for mechanistic evidence |
| Results mixed with implications | Put observation in Results and meaning in Discussion |
## Drafting from author notes
Use this sequence:
1. Summarize the author's intended claim in Chinese.
2. Identify missing evidence or boundary.
3. Draft the English paragraph.
4. Add short Chinese notes explaining any structural changes.
Do not make the English sound like a literal translation. Make it sound like a
Nature-style manuscript paragraph supported by the user's facts.

View File

@@ -0,0 +1,35 @@
# Conclusion Writing Guide
## Goal
Close the paper with clear takeaways and credible limitations.
## Structure
1. Restate solved problem and core technical idea.
2. Summarize strongest evidence from experiments.
3. State practical impact or new insight.
4. Add limitation paragraph.
5. End with concrete future direction.
## Limitation Guidance
Prefer limitations tied to task goal/setting boundaries, for example:
1. Data regime limitation (e.g., only short sequences).
2. Assumption limitation (e.g., controlled viewpoints only).
3. Deployment scope limitation (e.g., specific sensor setup).
Avoid framing conclusion around fixable implementation flaws unless they critically define your method's scope.
## Distinguish Limitation Types
1. Technical defect: underperforms strong baselines on key metrics or causes unacceptable tradeoff.
2. Scope limitation: bounded by current task setting and still competitive vs. current SOTA.
## Template
1. This paper addresses [problem] by proposing [method].
2. The key idea is [core insight], which enables [main benefit].
3. Experiments show [main gains] across [datasets/settings].
4. A current limitation is [scope boundary], and extending to [future setting] is an important next step.

View File

@@ -0,0 +1,13 @@
# Abstract Examples Index
All abstract example cites should point to the local files below.
1. Version 1 (Challenge -> Contribution)
`Version 1: Introduce the technical challenge, then use one to two sentences to present the technical contribution that solves the challenge.`
`references/examples/abstract/template-a.md`
2. Version 2 (Challenge -> Insight -> Contribution)
`Version 2: Introduce the technical challenge, then use one to two sentences to present the insight for solving the challenge, and then one sentence to present the technical contribution that implements this insight. (Personally recommended.)`
`references/examples/abstract/template-b.md`
3. Version 3 (Multiple Contributions)
`Version 3: When there are multiple technical contributions, describe each contribution together with its technical advantage.`
`references/examples/abstract/template-c.md`

View File

@@ -0,0 +1,21 @@
# Abstract Template A Examples (Challenge -> Contribution)
Source scope: your original notes, "Version 1".
```latex
\section{Abstract}
% Task
% Technical challenge for previous methods (discuss around the technical challenge that we solved)
% Introduce the technical contribution for solving the challenge in one to two sentences (usually mention the technical term/name only, without describing every detailed step. The term should be easy to understand and should not create a jump in reading. This ability is very important for writing a good abstract.)
% Introduce the benefits of the technical contribution
% Experiment
```
## Reusable skeleton
1. `[Task sentence]`
2. `However, previous methods suffer from [technical challenge].`
3. `To solve this challenge, we propose [technical contribution name].`
4. `[One more contribution sentence if needed].`
5. `This contribution brings [technical benefit].`
6. `Experiments show [main result].`

View File

@@ -0,0 +1,34 @@
# Abstract Template B Examples (Challenge -> Insight -> Contribution)
```latex
\section{Abstract}
% Task
%% Example 1: In recent years, generative models have undergone significant advancement due to the success of diffusion models.
%% Example 2: This paper addresses the challenge of novel view synthesis for a human performer from a very sparse set of camera views.
% Technical challenge for previous methods (discuss around the technical challenge that we solved)
%% Example 1: The success of these models is often attributed to their use of guidance techniques, such as classifier and classifier-free methods, which provides effective mechanisms to tradeoff between fidelity and diversity. However, these methods are not capable of guiding a generated image to be aware of its geometric configuration, e.g., depth, which hinders the application of diffusion models to areas that require a certain level of depth awareness.
%% Example 2: Some recent works have shown that learning implicit neural representations of 3D scenes achieves remarkable view synthesis quality given dense input views. However, the representation learning will be ill-posed if the views are highly sparse.
% Introduce the insight for solving the challenge in one sentence
%% Example 1: To address this limitation, we propose a novel guidance approach for diffusion models that uses estimated depth information derived from the rich intermediate representations of diffusion models.
%% Example 2: To solve this ill-posed problem, our key idea is to integrate observations over video frames.
% Introduce the technical contribution that implements the insight in one to two sentences (usually mention the technical term/name only, without describing every detailed step. The term should be easy to understand and should not create a jump in reading. This ability is very important for writing a good abstract.)
%% Example 1: To do this, we first present a label-efficient depth estimation framework using the internal representations of diffusion models. At the sampling phase, we utilize two guidance techniques to self-condition the generated image using the estimated depth map, the first of which uses pseudo-labeling, and the subsequent one uses a depth-domain diffusion prior.
%% Example 2: To this end, we propose Neural Body, a new human body representation which assumes that the learned neural representations at different frames share the same set of latent codes anchored to a deformable mesh
% Introduce the benefits of technical novelty
%% Example 2: so that the observations across frames can be naturally integrated. The deformable mesh also provides geometric guidance for the network to learn 3D representations more efficiently.
% Experiment
```
## Given example pattern 2
1. `This paper addresses the challenge of novel view synthesis for a human performer from a very sparse set of camera views.`
2. `... representation learning will be ill-posed if the views are highly sparse.`
3. `To solve this ill-posed problem, our key idea is to integrate observations over video frames.`
4. `To this end, we propose Neural Body ...`
5. `... observations across frames can be naturally integrated ... provides geometric guidance ...`
6. `Experiments show [main result].`

View File

@@ -0,0 +1,28 @@
# Abstract Template C Examples (Multiple Contributions)
```latex
% Task
%% This paper introduces a novel contour-based approach named deep snake for real-time instance segmentation.
%% Unlike some recent methods that directly regress the coordinates of the object boundary points from an image
% Introduce technical contribution and technical advantage in one sentence (this ability is very important for writing a good abstract.)
%% deep snake uses a neural network to iteratively deform an initial contour to match the object boundary, which implements the classic idea of snake algorithms with a learning-based approach.
% Introduce technical contribution and technical advantage in one sentence
%% For structured feature learning on the contour, we propose to use circular convolution in deep snake, which better exploits the cycle-graph structure of a contour compared against generic graph convolution.
% Introduce technical contribution and technical advantage in one sentence
%% Based on deep snake, we develop a two-stage pipeline for instance segmentation: initial contour proposal and contour deformation, which can handle errors in object localization.
% Experiment
```
## Given example pattern (Deep Snake style from your text)
1. `This paper introduces a novel contour-based approach named deep snake for real-time instance segmentation.`
2. `Unlike some recent methods that directly regress the coordinates of the object boundary points from an image ...`
3. `deep snake uses a neural network to iteratively deform an initial contour ...`
4. `For structured feature learning on the contour, we propose circular convolution ...`
5. `Based on deep snake, we develop a two-stage pipeline ...`
6. `Experiments show [main result].`

View File

@@ -0,0 +1,21 @@
# Example Bank Index
Use this folder for concrete writing patterns and locally organized cite targets.
## Files
1. Abstract examples index: `references/examples/abstract-examples.md`
2. Introduction examples index: `references/examples/introduction-examples.md`
3. Abstract template files: `references/examples/abstract/template-a.md`, `references/examples/abstract/template-b.md`, `references/examples/abstract/template-c.md`
4. Introduction task/application files: `references/examples/introduction/version-1-task-then-application.md`, `references/examples/introduction/version-2-application-first.md`, `references/examples/introduction/version-3-general-to-specific-setting.md`, `references/examples/introduction/version-4-open-with-challenge.md`
5. Introduction technical-challenge files: `references/examples/introduction/technical-challenge-version-1-existing-task.md`, `references/examples/introduction/technical-challenge-version-2-existing-task-insight-backed-by-traditional.md`, `references/examples/introduction/technical-challenge-version-3-novel-task.md`, `references/examples/introduction/novel-task-challenge-decomposition.md`
6. Introduction pipeline files: `references/examples/introduction/pipeline-version-1-one-contribution-multi-advantages.md`, `references/examples/introduction/pipeline-version-2-two-contributions.md`, `references/examples/introduction/pipeline-version-3-new-module-on-existing-pipeline.md`, `references/examples/introduction/pipeline-version-4-observation-driven.md`, `references/examples/introduction/pipeline-not-recommended-abstract-only.md`
7. Method examples index: `references/examples/method-examples.md`
8. Method detail files: `references/examples/method/pre-writing-questions.md`, `references/examples/method/module-triad-neural-body.md`, `references/examples/method/neural-body-annotated-figure-text.md`, `references/examples/method/module-design-instant-ngp.md`, `references/examples/method/module-motivation-patterns.md`, `references/examples/method/section-skeleton.md`, `references/examples/method/overview-template.md`, `references/examples/method/example-of-the-three-elements.md`, `references/examples/method/method-writing-common-issues-note.md`
## Usage
1. Pick one template from a section guide.
2. Open the matching examples file.
3. Reuse the sentence logic, not exact wording.
4. Keep citation links in your notes for traceability.

View File

@@ -0,0 +1,25 @@
# Introduction Examples Index
All introduction example cites should point to the local files below.
## A. Task and Application Versions
1. Version 1: `references/examples/introduction/version-1-task-then-application.md`
2. Version 2: `references/examples/introduction/version-2-application-first.md`
3. Version 3: `references/examples/introduction/version-3-general-to-specific-setting.md`
4. Version 4: `references/examples/introduction/version-4-open-with-challenge.md`
## B. Technical Challenge Versions
1. Version 1 (existing task): `references/examples/introduction/technical-challenge-version-1-existing-task.md`
2. Version 2 (existing task + traditional insight backing): `references/examples/introduction/technical-challenge-version-2-existing-task-insight-backed-by-traditional.md`
3. Version 3 (novel task): `references/examples/introduction/technical-challenge-version-3-novel-task.md`
4. Novel-task decomposition examples: `references/examples/introduction/novel-task-challenge-decomposition.md`
## C. Pipeline-Introduction Versions
1. Version 1: `references/examples/introduction/pipeline-version-1-one-contribution-multi-advantages.md`
2. Version 2: `references/examples/introduction/pipeline-version-2-two-contributions.md`
3. Version 3: `references/examples/introduction/pipeline-version-3-new-module-on-existing-pipeline.md`
4. Version 4: `references/examples/introduction/pipeline-version-4-observation-driven.md`
5. Not recommended pattern: `references/examples/introduction/pipeline-not-recommended-abstract-only.md`

View File

@@ -0,0 +1,18 @@
# Introduction Novel-Task Challenge Decomposition
`For novel tasks without direct methods, decompose the challenge into clear requirement/challenge points.`
```latex
% To achieve xx goal, several requirements must be satisfied (or several challenges must be handled).
%% Example: In this work, our goal is to build a model that captures such object intrinsics from a single image. This problem is challenging for three reasons.
% Describe point 1
%% Example: First, we only have a single image. This makes our work fundamentally different from existing works on 3D-aware image generation models [8, 9, 27, 28], which typically require a large dataset of thousands of instances for training. In comparison, the single image contains at most a few dozen instances, making the inference problem highly under-constrained.
% Describe point 2
%% Example: Second, these already limited instances may vary significantly in pixel values. This is because they have different poses and illumination conditions, but neither of these factors are annotated or known. We also cannot resort to existing tools for pose estimation based on structure from motion, such as COLMAP [35], because the appearance variations violate the assumptions of epipolar geometry.
% Describe point 3
%% Example: Finally, the object intrinsics we aim to infer are probabilistic, not deterministic: no two roses in the natural world are identical, and we want to capture a distribution of their geometry, texture, and material to exploit the underlying multi-view information.
```

View File

@@ -0,0 +1,30 @@
# Not Recommended: Abstract-Only Method Description in Introduction
`Not recommended: If the method is simple, do not avoid concrete method details in Introduction and only discuss abstract insight to make it look novel.`
Expert note (faithful translation):
1. The craft of this writing template is how to make a simple pipeline look novel.
2. Note: this is not about making the insight look novel, but about making the pipeline steps look novel.
3. In most cases this is not recommended.
4. The better target is to clearly explain how the core contribution is implemented in Introduction.
```latex
% To tackle this problem, we propose a novel 3D GAN training method to generate photo-realistic images irrespective of the viewing angle.
% Introduce key idea
% Our key idea is as follows. To ease the challenging problem of learning photorealistic and multi-view consistent image synthesis, we cast the problem into two subproblems, each of which can be solved more easily.
% Explain why the key idea works, but without concretely discussing the full pipeline (or only discuss abstract benefit)
%% Example: Specifically, we formulate the problem as a combination of two simple discrimination problems, one of which learns to discriminate whether a synthesized image looks real or not, and the other learns to discriminate whether a synthesized image agrees with the camera pose. Unlike the formulations of the previous methods, which try to learn the real image distribution for each pose, or to learn pose estimation, our subproblems are much easier as each of them is analogous to a basic binary classification problem.
% Introduce pipeline modules with new terms but without clearly explaining the full pipeline (or skip concrete pipeline details)
%% Example: Based on this key idea, we propose a dual-branched discriminator, which has two branches for learning photorealism and pose consistency, respectively. As these branches are supervised explicitly for their respective purposes, high-quality images with pose consistency can be produced at each viewing angle, and consequently, the generator creates high-quality images and shapes. (This paragraph does not clearly explain how the pipeline works.)
% Introduce another contribution
%% Example: In addition, we propose a pose-matching loss to give supervision to the discriminator for the pose consistency, by considering a positive pose (i.e., rendering pose or ground truth pose) and a negative pose (i.e., irrelevant pose) for a given image. (This paragraph does not clearly explain how the pipeline works.)
% Explain expected benefit over prior methods
%% Example: For example, the frontal viewpoint is one of the irrelevant poses for a side-view image. As reported in the experiments, this loss helps improve image and shape quality. This can be interpreted as a simplification of a classification problem from a large number of classes into binary, which is composed of positive and negative pairs.
```

View File

@@ -0,0 +1,30 @@
# Pipeline Version 1 (One Contribution, Multiple Advantages)
`Version 1: One contribution with multiple advantages, and one teaser figure to present the basic idea.`
```latex
% In this paper, we propose a novel framework …
%% Example: In this paper, we introduce a novel implicit neural representation for dynamic humans, named Neural Body, to solve the challenge of novel view synthesis from sparse views.
In this paper, we propose a novel framework/representation, named [method name] for [xxx task].
% Teaser for basic idea
%% Example: The basic idea is illustrated in Figure 2.
The basic idea is illustrated in [xxx Figure].
% One-sentence key novelty/contribution (very important ability)
%% Example: For the implicit fields at different frames, instead of learning them separately, Neural Body generates them from the same set of latent codes.
Our innovation is in [one sentence for key novelty].
% Method details
%% Example: Specifically, we anchor a set of latent codes to the vertices of a deformable human model (SMPL in this work), namely that their spatial locations vary with the human pose. To obtain the 3D representation at a frame, we first transform the code locations based on the human pose, which can be reliably estimated from sparse camera views. Then, a network is designed to regress the density and color for any 3D point based on these latent codes. Both the latent codes and the network are jointly learned from images of all video frames during the reconstruction.
Specifically, [how it works in detail].
% Advantage 1
%% Example: This model is inspired by the latent variable model in statistics, which enables us to effectively integrate observations at different frames.
In contrast to previous methods, [our advantage].
% Advantage 2
%% Example: Another advantage of the proposed method is that the deformable model provides a geometric prior (rough surface location) to enable more efficient learning of implicit fields.
Another advantage of the proposed method is that [another advantage].
```

View File

@@ -0,0 +1,34 @@
# Pipeline Version 2 (Two Contributions)
`Version 2: Two contributions, and one teaser figure to present the basic idea.`
```latex
% In this paper, we propose a novel framework …
%% Example: In this paper, we introduce a novel implicit neural representation for dynamic humans, named Neural Body, to solve the challenge of novel view synthesis from sparse views.
In this paper, we propose a novel framework/representation, named [method name] for [xxx task].
% One-sentence key novelty
%% Example: To that end, we propose techniques to represent a given subject with rare token identifiers and fine-tune a pre-trained, diffusion-based text-to-image framework that operates in two steps; generating a low-resolution image from text and subsequently applying super-resolution (SR) diffusion models.
Our innovation is in [one sentence for key novelty].
% Teaser
%% Example: The basic idea is illustrated in Figure 2.
The basic idea is illustrated in [xxx Figure].
% Contribution 1 details
%% Example: We first fine-tune the low-resolution text-to-image model with the input images and text prompts containing a unique identifier followed by the class name of the subject (e.g., “A [V] dog”).
Specifically, [how contribution 1 works].
% Advantage of contribution 1
%% Example: This model is inspired by the latent variable model in statistics, which enables us to effectively integrate observations at different frames.
In contrast to previous methods, [advantage of contribution 1].
% Challenge motivating contribution 2
%% Example: In order to prevent overfitting and language drift [35, 40] that cause the model to associate the class name (e.g., “dog”) with the specific instance
However, [another technical challenge].
% Contribution 2 details
%% Example: we propose an autogenous, class-specific prior preservation loss, which leverages the semantic prior on the class that is embedded in the model, and encourages it to generate diverse instances of the same class as our subject.
Specifically, [how contribution 2 works].
```

View File

@@ -0,0 +1,18 @@
# Pipeline Version 3 (New Module on Existing Pipeline)
`Version 3: Build on a prior pipeline and introduce one new module, with a teaser figure for the basic idea.`
```latex
% In this paper, we propose a learning-based snake algorithm, named deep snake, for real-time instance segmentation.
% Inspired by previous methods [21, 25], deep snake takes an initial contour as input and deforms it by regressing vertex-wise offsets.
% Our innovation is introducing the circular convolution for efficient feature learning on a contour, as illustrated in Figure 1.
% We observe that the contour is a cycle graph that consists of a sequence of vertices connected in a closed cycle. Since every vertex has the same degree equal to two, we can apply the standard 1D convolution on the vertex features.
% Considering that the contour is periodic, deep snake introduces the circular convolution, which indicates that an aperiodic function (1D kernel) is convolved in the standard way with a periodic function (features defined on the contour).
% The kernel of circular convolution encodes not only the feature of each vertex but also the relationship among neighboring vertices. In contrast, the generic GCN performs pooling to aggregate information from neighboring vertices. The kernel function in our circular convolution amounts to a learnable aggregation function, which is more expressive and results in better performance than using a generic GCN, as demonstrated by our experimental results in Section 5.2.
```

View File

@@ -0,0 +1,16 @@
# Pipeline Version 4 (Observation-Driven Contribution)
`Version 4: Contribution comes from one important observation. Introduce key innovation first, then intuitive observation as motivation, then method details, then benefits.`
```latex
% In this paper, we propose a learning-based snake algorithm, named deep snake, for real-time instance segmentation.
% Our innovation is introducing the circular convolution for efficient feature learning on a contour, as illustrated in Figure 1.
% We observe that the contour is a cycle graph that consists of a sequence of vertices connected in a closed cycle. Since every vertex has the same degree equal to two, we can apply the standard 1D convolution on the vertex features.
% Considering that the contour is periodic, deep snake introduces the circular convolution, which indicates that an aperiodic function (1D kernel) is convolved in the standard way with a periodic function (features defined on the contour).
% The kernel of circular convolution encodes not only the feature of each vertex but also the relationship among neighboring vertices. In contrast, the generic GCN performs pooling to aggregate information from neighboring vertices. The kernel function in our circular convolution amounts to a learnable aggregation function, which is more expressive and results in better performance than using a generic GCN, as demonstrated by our experimental results in Section 5.2.
```

View File

@@ -0,0 +1,32 @@
# Technical Challenge Version 1 (Existing Task, Existing Methods)
`Version 1: For existing tasks with existing methods, discuss the challenge chain from traditional methods to recent methods and finally to the challenge we solve.`
```latex
% Discuss general technical challenges of this task (to lead into recent methods)
%% Example 1: This problem is quite challenging from many perspectives, including object detection under severe occlusions, variations in lighting and appearance, and cluttered background objects.
%% Example 2: This problem is particularly challenging due to the inherent ambiguity on acquiring human geometry, materials and motions from images.
This problem is particularly challenging due to several factors, including [xxx reason], [xxx reason], and [xxx reason].
% Briefly introduce one class of traditional methods, then discuss their technical challenge
%% Example: Traditional methods have shown that pose estimation can be achieved by establishing the correspondences between an object image and the object model.
To overcome these challenges, traditional methods [how they work], [what they achieve].
%% Example: They rely on hand-crafted features, which are not robust to image variations and background clutters.
However, they [technical challenge they face].
% Briefly introduce one class of recent methods 1 (optional), then discuss their challenge
%% Example: Deep learning based methods train end-to-end neural networks that take an image as input and output its corresponding pose.
Recently, [xxx methods] [how they work], [what they achieve].
%% Example: However, generalization remains as an issue, as it is unclear that such end-to-end methods learn sufficient feature representations for pose estimation.
However, they [limitation], because [xxx technical reason].
% Briefly introduce one class of recent methods 2, then discuss their challenge (must lead to our solved challenge)
%% Example: Some recent methods use CNNs to first regress 2D keypoints and then compute 6D pose parameters using the Perspective-n-Point (PnP) algorithm. In other words, the detected keypoints serve as an intermediate representation for pose estimation. Such two-stage approaches achieve state-of-the-art performance, thanks to robust detection of keypoints.
To overcome this challenge, [xxx methods] [how they work], [what they achieve].
%% Example: However, these methods have difficulty in tackling occluded and truncated objects, since part of their keypoints are invisible. Although CNNs may predict these unseen keypoints by memorizing similar patterns, generalization remains difficult.
However, they [limitation], because [xxx technical reason].
```

View File

@@ -0,0 +1,33 @@
# Technical Challenge Version 2 (Existing Task, Insight Backed by Traditional Methods)
`Version 2: For existing tasks, if our technical insight was used in traditional methods, discuss that line to provide conceptual backing.`
```latex
% Introduce one class of traditional/recent methods and discuss their technical challenge (to lead to our insight)
%% Example (Deep Snake): Most of the state-of-the-art instance segmentation methods perform pixel-wise segmentation within a bounding box given by an object detector.
%% Example (ManhattanSDF): Given input images, traditional methods generally estimate the depth map for each image based on the multi-view stereo (MVS) algorithms and then fuse estimated depth maps into 3D models.
Traditional/recent methods [how they work], [what they achieve].
%% Example (Deep Snake): They may be sensitive to the inaccurate bounding box. Moreover, representing an object shape as dense binary pixels generally results in costly post-processing.
%% Example (ManhattanSDF): Although these methods achieve successful reconstruction in most cases, they have difficulty in handling low-textured regions, e.g., floors and walls of indoor scenes, due to the unreliable stereo matching in these regions.
However, they [limitation], because [xxx technical reason].
% Discuss traditional methods that used an insight similar to ours (implicitly backing our idea)
%% Example (Deep Snake): An alternative shape representation is the object contour, which is a set of vertices along the object silhouette. In contrast to pixel-based representation, a contour is not limited within a bounding box and has fewer parameters. Such a contour-based representation has long been used in image segmentation since the seminal work by Kass et al., which is well known as snakes or active contours.
%% Example (ManhattanSDF): To improve the reconstruction of low-textured regions, a typical approach is leveraging the planar prior of manmade scenes, which has long been explored in literature. A renowned example is the Manhattanworld assumption, i.e., the surfaces of man-made scenes should be aligned with three dominant directions.
To overcome this problem, a typical approach is [xxx insight], which has long been explored in literature.
These methods [how they work].
%% Example (Deep Snake): While many variants have been developed in literature, these methods are prone to local optima as the objective functions are handcrafted and typically nonconvex.
%% Example (ManhattanSDF): However, all of them focus on optimizing per-view depth maps instead of the full scene models in 3D space. As a result, depth estimation and plane segmentation could still be inconsistent among views, yielding suboptimal reconstruction quality as demonstrated by our experimental results in Section 5.3.
However, they [limitation], because [xxx technical reason].
% Then discuss newer methods and their remaining challenge (must lead to our solved challenge)
%% Example: There is a recent trend to represent 3D scenes as implicit neural representations and learn the representations from images with differentiable renderers. In particular, [49, 54, 55] use a signed distance field (SDF) to represent the scene and render it into images based on the sphere tracing or volume rendering. Thanks to the well-defined surfaces of SDFs, they recover high-quality 3D geometries from images.
To overcome this challenge, [xxx methods] [how they work], [what they achieve].
%% Example: However, these methods essentially rely on the multi-view photometric consistency to learn the SDFs. So they still suffer from poor performance in low-textured planar regions, as shown in Figure 1, as many plausible solutions may satisfy the photometric constraint in low-textured planar regions.
However, they [limitation], because [xxx technical reason].
```

View File

@@ -0,0 +1,21 @@
# Technical Challenge Version 3 (Novel Task)
`Version 3: For novel tasks without direct methods, define the challenge directly and decompose it by requirement/challenge points.`
```latex
% To achieve xx goal, several requirements/challenges must be satisfied.
%% Example: In this work, our goal is to build a model that captures such object intrinsics from a single image. This problem is challenging for three reasons.
% Describe point 1
%% Example: First, we only have a single image. This makes our work fundamentally different from existing works on 3D-aware image generation models [8, 9, 27, 28], which typically require a large dataset of thousands of instances for training. In comparison, the single image contains at most a few dozen instances, making the inference problem highly under-constrained.
% Describe point 2
%% Example: Second, these already limited instances may vary significantly in pixel values. This is because they have different poses and illumination conditions, but neither of these factors are annotated or known. We also cannot resort to existing tools for pose estimation based on structure from motion, such as COLMAP [35], because the appearance variations violate the assumptions of epipolar geometry.
% Describe point 3
%% Example: Finally, the object intrinsics we aim to infer are probabilistic, not deterministic: no two roses in the natural world are identical, and we want to capture a distribution of their geometry, texture, and material to exploit the underlying multi-view information.
```
See also:
1. `references/examples/introduction/novel-task-challenge-decomposition.md`

View File

@@ -0,0 +1,14 @@
# Introduction Version 1: Task First, Then Application
`Version 1: If the task is relatively niche, introduce the task first, then introduce applications.`
```latex
% Introduce Task (if the task is very familiar, this part can be skipped)
%% Example: Object pose estimation aims to estimate object's orientation and translation relative to a canonical frame from a single image.
[xxx task] targets at recovering/reconstructing/estimating [xxx output] from [xxx input].
% Introduce Application
%% Example: Accurate pose estimation is essential for a variety of applications such as augmented reality, autonomous driving and robotic manipulation.
[xxx task] has a variety of applications such as [xxx], [xxx], and [xxx].
```

View File

@@ -0,0 +1,10 @@
# Introduction Version 2: Application First
`Version 2: If the task is already familiar to most readers, introduce applications directly.`
```latex
% Introduce Application
%% Example: Accurate pose estimation is essential for a variety of applications such as augmented reality, autonomous driving and robotic manipulation.
[xxx task] has a variety of applications such as [xxx], [xxx], and [xxx].
```

View File

@@ -0,0 +1,14 @@
# Introduction Version 3: General Application -> Specific Setting
`Version 3: Introduce applications of the general task first, then introduce the specific task setting. (Personally recommended when the setting is relatively new.)`
```latex
% Introduce applications of the general task
%% Example: Accurate pose estimation is essential for a variety of applications such as augmented reality, autonomous driving and robotic manipulation.
[xxx task] has a variety of applications such as [xxx], [xxx], and [xxx].
% Introduce the specific task setting
%% Example: This paper focuses on the specific setting of recovering the 6DoF pose of an object, i.e., rotation and translation in 3D, from a single RGB image of that object.
This paper focuses on the specific setting of recovering/reconstructing/estimating [xxx output] from [xxx input].
```

View File

@@ -0,0 +1,20 @@
# Introduction Version 4: Open with Application and Challenge
`Version 4: If the task is familiar, introduce applications directly and expose the target technical challenge in the opening paragraph via previous methods.`
Expert notes (faithful translation):
1. It is often good if the opening paragraph already states what we want to solve.
2. But this style requires suitable conditions and is less common.
3. Usually, several prior-method paragraphs are still needed before the target challenge becomes clear.
```latex
% Introduce Application
%% Example 1: Reconstructing 3D scenes from multi-view images is a cornerstone of many applications such as augmented reality, robotics, and autonomous driving.
%% Example 2: Instance segmentation is the cornerstone of many computer vision tasks, such as video analysis, autonomous driving, and robotic grasping, which require both accuracy and efficiency.
% Use previous methods to expose the target technical challenge
%% Example 1: Given input images, traditional methods [43, 44, 59] generally estimate the depth map for each image based on the multi-view stereo (MVS) algorithms and then fuse estimated depth maps into 3D models. Although these methods achieve successful reconstruction in most cases, they have difficulty in handling low-textured regions, e.g., floors and walls of indoor scenes, due to the unreliable stereo matching in these regions.
%% Example 2: Most of the state-of-the-art instance segmentation methods [18, 27, 5, 19] perform pixel-wise segmentation within a bounding box given by an object detector [36], which may be sensitive to the inaccurate bounding box. Moreover, representing an object shape as dense binary pixels generally results in costly post-processing.
```

View File

@@ -0,0 +1,24 @@
# Method Examples Index
All method example cites should point to the local files below.
## A. Planning and Writing Workflow
1. Pre-writing questions: `references/examples/method/pre-writing-questions.md`
## B. Module Triad and Module-Level Writing
1. Module triad (Neural Body): `references/examples/method/module-triad-neural-body.md`
2. Neural Body figure text conversion: `references/examples/method/neural-body-annotated-figure-text.md`
3. Module design (Instant-NGP): `references/examples/method/module-design-instant-ngp.md`
4. Module motivation patterns: `references/examples/method/module-motivation-patterns.md`
## C. Section-Level Templates
1. Method section skeleton: `references/examples/method/section-skeleton.md`
2. Overview template: `references/examples/method/overview-template.md`
3. Example of the three elements: `references/examples/method/example-of-the-three-elements.md`
## D. Clarity and Troubleshooting
1. Common issues note: `references/examples/method/method-writing-common-issues-note.md`

View File

@@ -0,0 +1,67 @@
# Example of the Three Elements
This example uses `%` comments as annotations.
Each `% ...` annotation explains the paragraph(s) immediately below it.
```latex
\begin{quote}
\textbf{Annotation rule.} In this example, each line starting with \% labels the role of the paragraph(s) directly below it.
\end{quote}
\begin{itemize}
\item Module design (data structure)
\item Motivation of this module
\item Technical advantages of this module
\item Module design (forward process)
\end{itemize}
\subsection{3.1. Structured latent codes}
% Module design: introduce the module's data structure
To control the spatial locations of latent codes with the human pose, we anchor these latent codes to a deformable human body model (SMPL) [38]. SMPL is a skinned vertex-based model, which is defined as a function of shape parameters, pose parameters, and a rigid transformation relative to the SMPL coordinate system. The function outputs a posed 3D mesh with 6890 vertices. Specifically, we define a set of latent codes \( Z = \{z_1, z_2, ..., z_{6890}\} \) on vertices of the SMPL model. For the frame \( t \), SMPL parameters \( S_t \) are estimated from the multi-view images \( \{I_t^c \mid c = 1, ..., N_c\} \) using [26]. The spatial locations of the latent codes are then transformed based on the human pose \( S_t \) for the density and color regression. Figure 3 shows an example. The dimension of latent code \( z \) is set to 16 in our experiments.
% Technical advantages of this module
Similar to the local implicit representations [25, 5, 18], the latent codes are used with a neural network to represent the local geometry and appearance of a human. Anchoring these codes to a deformable model enables us to represent a dynamic human. With the dynamic human representation, we establish a latent variable model that maps the same set of latent codes to the implicit fields of density and color at different frames, which naturally integrates observations at different frames.
\subsection{3.2. Code diffusion}
% Motivation of this module
Figure 3(a) shows the process of code diffusion. The implicit fields assign the density and color to each point in the 3D space, which requires us to query the latent codes at continuous 3D locations. This can be achieved with the trilinear interpolation. However, since the structured latent codes are relatively sparse in the 3D space, directly interpolating the latent codes leads to zero vectors at most 3D points. To solve this problem, we diffuse the latent codes defined on the surface to nearby 3D space.
% Module design: introduce module design by describing the module forward process
Inspired by [65, 56, 49], we choose the SparseConvNet [21] to efficiently process the structured latent codes, whose architecture is described in Table 1. Specifically, based on the SMPL parameters, we compute the 3D bounding box of the human and divide the box into small voxels with voxel size of \( 5mm \times 5mm \times 5mm \). The latent code of a non-empty voxel is the mean of latent codes of SMPL vertices inside this voxel. SparseConvNet utilizes 3D sparse convolutions to process the input volume and output latent code volumes with \( 2\times, 4\times, 8\times, 16\times \) downsampled sizes. With the convolution and downsampling, the input codes are diffused to nearby space. Following [56], for any point in 3D space, we interpolate the latent codes from multi-scale code volumes of network layers 5, 9, 13, 17, and concatenate them into the final latent code. Since the code diffusion should not be affected by the human position and orientation in the world coordinate system, we transform the code locations to the SMPL coordinate system.
For any point \( \mathbf{x} \) in 3D space, we query its latent code from the latent code volume. Specifically, the point \( \mathbf{x} \) is first transformed to the SMPL coordinate system, which aligns the point and the latent code volume in 3D space. Then, the latent code is computed using the trilinear interpolation. For the SMPL parameters \( S_t \), we denote the latent code at point \( \mathbf{x} \) as \( \psi(\mathbf{x}, Z, S_t) \). The code vector is passed into MLP networks to predict the density and color for point \( \mathbf{x} \).
\subsection{3.3. Density and color regression}
Figure 3(b) overviews the regression of density and color for any point in 3D space. The density and color fields are represented by MLP networks. Details of network architectures are described in the supplementary material.
% Module design: introduce module design by describing the module forward process
\textbf{Density model.} For the frame \( t \), the volume density at point \( \mathbf{x} \) is predicted as a function of only the latent code \( \psi(\mathbf{x}, Z, S_t) \), which is defined as:
\[
\sigma_t(\mathbf{x}) = M_{\sigma}(\psi(\mathbf{x}, Z, S_t)),
\tag{1}
\]
where \( M_{\sigma} \) represents an MLP network with four layers.
% Module design: introduce the module's data structure
\textbf{Color model.} Similar to [37, 44], we take both the latent code \( \psi(\mathbf{x}, Z, S_t) \) and the viewing direction \( \mathbf{d} \) as input for the color regression. To model the location-dependent incident light, the color model also takes the spatial location \( \mathbf{x} \) as input. We observe that temporally-varying factors affect the human appearance, such as secondary lighting and self-shadowing. Inspired by the auto-decoder [48], we assign a latent embedding \( \ell_t \) for each video frame \( t \) to encode the temporally-varying factors.
% Module design: introduce module design by describing the module forward process
Specifically, for the frame \( t \), the color at \( \mathbf{x} \) is predicted as a function of the latent code \( \psi(\mathbf{x}, Z, S_t) \), the viewing direction \( \mathbf{d} \), the spatial location \( \mathbf{x} \), and the latent embedding \( \ell_t \). Following [51, 44], we apply the positional encoding to both the viewing direction \( \mathbf{d} \) and the spatial location \( \mathbf{x} \), which enables better learning of high frequency functions. The color model at frame \( t \) is defined as:
\[
c_t(\mathbf{x}) = M_c(\psi(\mathbf{x}, Z, S_t), \gamma_d(\mathbf{d}), \gamma_x(\mathbf{x}), \ell_t),
\tag{2}
\]
where \( M_c \) represents an MLP network with two layers, and \( \gamma_d \) and \( \gamma_x \) are positional encoding functions for viewing direction and spatial location, respectively. We set the dimension of \( \ell_t \) to 128 in experiments.
\subsection{3.4. Volume rendering}
% Module design: introduce module design by describing the module forward process
Given a viewpoint, we utilize the classical volume rendering techniques to render the Neural Body into a 2D image. The pixel colors are estimated via the volume rendering integral equation [27] that accumulates volume densities and colors along the corresponding camera ray. In practice, the integral is approximated using numerical quadrature [41, 44]. Given a pixel, we first compute its camera ray \( \mathbf{r} \) using the camera parameters and sample \( N_k \) points \( \{\mathbf{x}_k\}_{k=1}^{N_k} \) along camera ray \( \mathbf{r} \) between near and far bounds. The scene bounds are estimated based on the SMPL model. Then, Neural Body predicts volume densities and colors at these points. For the video frame \( t \), the rendered color \( \hat{C}_t(\mathbf{r}) \) ...
```

View File

@@ -0,0 +1,10 @@
# Method Writing Common Issues (Reference Note)
Original source mentioned in your notes:
1. `Method writing common issues (PDF in your source notes)`
Usage recommendation:
1. Use this reference as a troubleshooting checklist after drafting Method.
2. Prioritize unclear motivation, broken flow, missing implementation details, and inconsistent terms.

View File

@@ -0,0 +1,55 @@
# Module Design Example
This example uses `%` comments as annotations.
Each `% ...` annotation explains the paragraph(s) immediately below it.
```latex
\begin{quote}
\textbf{Annotation rule.} In this example, each line starting with \% labels the role of the paragraph(s) directly below it.
\end{quote}
\begin{itemize}
\item Motivation of this module
\item Module design (data structure)
\item Module design (forward process)
\end{itemize}
\section{3 \quad MULTIRESOLUTION HASH ENCODING}
% Motivation of this module
Given a fully connected neural network \(m(y;\Phi)\), we are interested in an encoding of its inputs \(y=\operatorname{enc}(x;\theta)\) that improves the approximation quality and training speed across a wide range of applications without incurring a notable performance overhead.
% Module design: introduce the module's data structure
Our neural network not only has trainable weight parameters \(\Phi\), but also trainable encoding parameters \(\theta\). These are arranged into \(L\) levels, each containing up to \(T\) feature vectors with dimensionality \(F\). Typical values for these hyperparameters are shown in Table 1. Figure 3 illustrates the steps performed in our multiresolution hash encoding. Each level (two of which are shown as red and blue in the figure) is independent and conceptually stores feature vectors at the vertices of a grid, the resolution of which is chosen to be a geometric progression between the coarsest and finest resolutions \([N_{\min},N_{\max}]\):
\[
N_l := \left\lfloor N_{\min}\cdot b^l \right\rfloor, \tag{2}
\]
\[
b := \exp\!\left(\frac{\ln N_{\max}-\ln N_{\min}}{L-1}\right). \tag{3}
\]
\(N_{\max}\) is chosen to match the finest detail in the training data. Due to the large number of levels \(L\), the growth factor is usually small. Our use cases have \(b\in[1.26,2]\).
% Module design: introduce module design by describing the module forward process
Consider a single level \(l\). The input coordinate \(x\in\mathbb{R}^d\) is scaled by that level's grid resolution before rounding down and up:
\[
\lfloor x_l \rfloor := \lfloor x\cdot N_l \rfloor,\quad
\lceil x_l \rceil := \lceil x\cdot N_l \rceil.
\]
\(\lfloor x_l \rfloor\) and \(\lceil x_l \rceil\) span a voxel with \(2^d\) integer vertices in \(\mathbb{Z}^d\). We map each corner to an entry in the level's respective feature vector array, which has fixed size of at most \(T\). For coarser levels where a dense grid requires fewer than \(T\) parameters, i.e. \((N_l+1)^d \le T\), this mapping is 1:1. At finer levels, we use a hash function \(h:\mathbb{Z}^d\rightarrow\mathbb{Z}_T\) to index into the array, effectively treating it as a hash table, although there is no explicit collision handling. We rely instead on the gradient-based optimization to store appropriate sparse detail in the array, and the subsequent neural network \(m(y;\Phi)\) for collision resolution. The number of trainable encoding parameters \(\theta\) is therefore \(O(T)\) and bounded by \(T\cdot L\cdot F\), which in our case is always \(T\cdot16\cdot2\) (Table 1).
We use a spatial hash function [Teschner et al. 2003] of the form
\[
h(x)=\left(\bigoplus_{i=1}^{d} x_i\pi_i\right)\bmod T, \tag{4}
\]
where \(\oplus\) denotes the bit-wise XOR operation and \(\pi_i\) are unique, large prime numbers. Effectively, this formula XORs the results of a per-dimension linear congruential (pseudo-random) permutation [Lehmer 1951], \emph{decorrelating} the effect of the dimensions on the hashed value. Notably, to achieve (pseudo-)independence, only \(d-1\) of the \(d\) dimensions must be permuted, so we choose \(\pi_1:=1\) for better cache coherence, \(\pi_2=2{,}654{,}435{,}761\), and \(\pi_3=805{,}459{,}861\).
Lastly, the feature vectors at each corner are \(d\)-linearly interpolated according to the relative position of \(x\) within its hypercube, i.e. the interpolation weight is \(w_l := x_l-\lfloor x_l \rfloor\).
Recall that this process takes place independently for each of the \(L\) levels. The interpolated feature vectors of each level, as well as auxiliary inputs \(\xi\in\mathbb{R}^E\) (such as the encoded view direction and textures in neural radiance caching), are concatenated to produce \(y\in\mathbb{R}^{LF+E}\), which is the encoded input \(\operatorname{enc}(x;\theta)\) to the MLP \(m(y;\Phi)\).
\textbf{Performance vs. quality.} Choosing the hash table size \(T\) provides a trade-off between performance, memory and quality. Higher values of \(T\) result in higher quality and lower performance. The memory ...
```

View File

@@ -0,0 +1,15 @@
# Module Motivation Writing Patterns
`Module motivation is usually problem-driven: because a problem exists, we design xx to solve it.`
Typical opening sentences:
1. `A remaining problem/challenge is ...`
2. `However, we ...`
3. `Previous methods have difficulty in ...`
Usage note:
1. State the specific failure before introducing the module.
2. Keep motivation independent from implementation details.

View File

@@ -0,0 +1,19 @@
# Module Triad Example (Neural Body)
`Use Neural Body to understand the three elements of a module: design, motivation, and technical advantages.`
Local source references:
1. Annotated figure showing motivation/design/advantages split.
3. Text-converted annotation notes: `references/examples/method/neural-body-annotated-figure-text.md`
Triad mapping template:
1. Module design: what representation/network is built and how forward process runs.
2. Motivation: what unresolved challenge requires this module.
3. Technical advantages: why this module performs better than alternatives.
Direct usage:
1. Read `neural-body-annotated-figure-text.md` to map each paragraph to one triad element.
2. Rebuild your own Method subsection with the same triad order.

View File

@@ -0,0 +1,66 @@
# Neural Body Annotated Figure (Text Conversion)
This file converts the annotated Neural Body figure into reusable writing notes.
## Purpose
Use this mapping to understand how one Method section can explicitly separate:
1. Module motivation
2. Module design (data structure)
3. Module design (forward process)
4. Technical advantages
## Block-by-Block Mapping
### Section 3.1: Structured Latent Codes
1. **Module design (data structure)**
- The paragraph defines structured latent codes anchored to the deformable human model (SMPL).
- It explains what is constructed (latent codes + their anchor positions + frame-dependent transformation by pose).
2. **Technical advantages**
- The paragraph explains why this design works better: dynamic-human representation and cross-frame integration of observations.
- It highlights why anchoring codes to deformable geometry is beneficial.
### Section 3.2: Code Diffusion
1. **Motivation of this module**
- The paragraph states the remaining problem: direct interpolation of sparse structured codes leads to near-zero vectors at many 3D points.
- This motivates diffusion from surface codes to nearby 3D space.
2. **Module design (forward process)**
- The paragraph explains the execution pipeline: build sparse latent volumes, run sparse convolutions, interpolate latent codes at query points, and feed codes to prediction networks.
- This is a canonical input -> steps -> output module description.
### Section 3.3: Density and Color Regression
1. **Module design (forward process) for density model**
- The density paragraph defines how density is regressed from latent code and frame condition.
2. **Module design (data structure) for color model**
- The color paragraph introduces required inputs/embeddings (latent code, view direction, spatial location, temporal embedding).
3. **Module design (forward process) for color model**
- The next paragraph describes how those inputs are encoded and passed into the color MLP for final color prediction.
### Section 3.4: Volume Rendering
1. **Module design (forward process)**
- The paragraph describes ray sampling and volume integration to render image outputs from predicted density/color fields.
## Reusable Writing Pattern from This Figure
For each module subsection, follow this order:
1. `Motivation`: state unresolved challenge and technical reason.
2. `Design-1`: define structure/representation/network.
3. `Design-2`: describe forward process in execution order.
4. `Advantage`: explain why this module improves over alternatives.
## Suggested Paragraph Starters
1. Motivation: `A remaining challenge is ...`
2. Data structure design: `We represent ... with ...`
3. Forward process: `Given [input], we first ... then ... finally ...`
4. Technical advantage: `Compared with previous methods, this design ... because ...`

View File

@@ -0,0 +1,30 @@
# Method Overview Template
`Overview usually includes setting, core contribution, optional figure pointer, and subsection map.`
```latex
% Overview
% One or two sentences for setting
%% Example 1: Given a sparse multi-view video of a performer, our task is to generate a free-viewpoint video of the performer.
%% Example 2: Given an image, the task of pose estimation is to detect objects and estimate their orientations and translations in the 3D space.
% One or two sentences for core contribution
%% Example 1: We build upon prior work for static scenes [46], to which we add the notion of time, and estimate 3D motion by explicitly modeling forward and backward scene flow as dense 3D vector fields.
%% Example 2: Inspired by [21, 25], we perform object segmentation by deforming an initial contour to match object boundary.
%% Example 3: Inspired by recent methods [29, 30, 36], we estimate the object pose using a two-stage pipeline: we first detect 2D object keypoints using CNNs and then compute 6D pose parameters using the PnP algorithm. Our innovation is in a new representation for 2D object keypoints as well as a modified PnP algorithm for pose estimation.
% If pipeline/framework is novel, point to figure
%% Example: The overview of the proposed model is illustrated in Figure 3.
% Explain what Section 3.1 covers
%% Example 1: Neural Body starts from a set of structured latent codes attached to the surface of a deformable human model (Section 3.1).
%% Example 2: In this section, we first describe how to model 3D scenes with MLP maps (Section 3.1).
% Explain what Section 3.2 covers
%% Example 1: The latent code at any location around the surface can be obtained with a code diffusion process (Section 3.2) and then decoded to density and color values by neural networks (Section 3.3).
%% Example 2: Then, Section 3.2 discusses how to represent volumetric videos with dynamic MLP maps.
% Explain what Section 3.3 covers
%% Example 3: Finally, we introduce some strategies to speed up the rendering process (Section 3.3).
```

View File

@@ -0,0 +1,17 @@
# Method Pre-Writing Questions
`Before writing Method, answer: (1) what modules exist, and (2) for each module, what is its workflow, why is it needed, and why does it work.`
```text
Questions:
(1) What modules are in the method?
(2) For each module, answer three questions:
- What is this module's workflow?
- Why do we need this module?
- Why does this module work?
```
Recommended action:
1. Organize answers in a mind map or table before writing paragraphs.

View File

@@ -0,0 +1,9 @@
# Method Section Skeleton
```latex
\section{Method}
% Overview
% Section 3.1
% Section 3.2
% Section 3.3
```

View File

@@ -0,0 +1,102 @@
# Experiments Writing Guide
## Goal
Convince reviewers with complete evidence on effectiveness, causality, and practical value.
## Three Core Questions
1. Is the method better than strong baselines?
- Run comparison experiments against strong and recent baselines.
- Report standard metrics on the main benchmark(s).
- Include SOTA or strongest public methods, not only weak baselines.
- Keep protocol fair (same data split, preprocessing, and evaluation settings).
2. Which modules/design choices make the gain?
- Run ablation studies for each key module/design choice.
- Use remove/replace/disable variants and report delta to full model.
- Include component interaction ablations when modules are coupled.
3. How far can the method generalize under harder settings?
- Run demos/evaluations on harder or out-of-distribution settings.
- Add stress-test scenarios (more complex scenes, rarer cases, noisier inputs, or stricter constraints).
- Report both gains and failure modes to show realistic boundaries.
## Experiment Planning
```mermaid
flowchart TB
A["Key Paper Claims"] --> B["What Contributions Are Claimed?"]
B --> C1["Contribution 1"]
B --> C2["Contribution 2"]
B --> C3["Contribution 3"]
C1 --> D1["Validation Experiment 1"]
C2 --> D2["Validation Experiment 2"]
C3 --> D3["Validation Experiment 3"]
E["Method Pipeline Figure"] --> F["What Modules and Parameters Matter?"]
F --> G1["Technical Module 1"]
F --> G2["Technical Module 2"]
F --> G3["Key Parameter 1"]
F --> G4["Key Parameter 2"]
G1 --> H1["Ablation Study 1"]
G2 --> H2["Ablation Study 2"]
G3 --> H3["Ablation Study 3"]
G4 --> H4["Ablation Study 4"]
```
## Experiment Section Decomposition
```mermaid
flowchart TB
S1["Experimental Setup"] --> S2["Validation Experiment 1"]
S2 --> S3["Validation Experiment 2"]
S3 --> S4["Ablation Studies"]
```
## Figure/Table Writing Rules
`Good tables are part of experiment communication quality, not decoration.`
1. Figure captions and table captions are equally important in the writing quality of Experiments.
### Hard rules
1. Put caption above the table.
2. Avoid vertical lines (`|`) in tabular columns.
3. Do not use double rules or dense `\hline` stacks.
4. Use `booktabs` style (`\toprule`, `\midrule`, `\bottomrule`) for clean structure.
5. Use as few horizontal rules as possible; lines should separate groups, not every row.
6. Highlight key numbers (best/second-best or target rows) with subtle color emphasis.
### Readability rules from review practice
1. Label metric direction in column headers (for example `PSNR ↑`, `LPIPS ↓`).
2. Add units when needed so values are interpretable without guessing.
3. Align text columns left; keep numeric columns consistently aligned.
4. Keep numeric precision consistent (same decimal places within a metric column).
5. Group multi-dataset or multi-setting results using `\multicolumn` + `\cmidrule`, not vertical separators.
6. One table, one message: do not mix unrelated results in a single table.
7. If rows represent different attributes/ablations, encode that explicitly in row names or attribute columns.
8. Keep caption focused on setting/protocol/notation, not long discussion.
9. If there is little detail to explain, use one concise sentence to summarize the main result.
10. For single-column figures/tables in two-column papers, prefer placing them in the right column when layout allows, so readers can enter the page from the left-top text without breaking reading flow.
### Minimal LaTeX checklist
1. Add packages in preamble: `\usepackage{booktabs}`, `\usepackage{colortbl,xcolor}` (and optionally `\usepackage{siunitx}` for decimal alignment).
2. Replace `\hline`-heavy style with `\toprule/\midrule/\bottomrule`.
3. Put `\caption{...}` before `\label{...}` and keep caption above.
4. Use restrained highlighting; never color too many cells.
## Recommended Ablation Package
1. One core ablation table for all major contributions.
2. Several focused mini-ablations for module-level design choices.
3. Matching qualitative visual results for each important ablation.
## Experimental Rigor Checklist
1. Are baselines recent and relevant?
2. Are metrics sufficient and standard for this task?
3. Is ablation tied to every key design claim?
4. Are claims in Abstract/Introduction supported by reported numbers?
5. Are limitations of evaluation scope explicitly stated?

View File

@@ -0,0 +1,408 @@
# Introduction Writing Guide
## Goal
Write a strong introduction in three steps:
1. Think through the introduction logic.
2. Apply a suitable template below.
3. Revise the introduction repeatedly.
## Introduction Logic Map
```mermaid
graph LR
L1[What task are we solving]
L2[Which metrics should this task improve]
L3[SOTA methods fail to meet target metrics]
L4[Root technical issue behind this failure]
L5[Our technical solution and method pipeline]
L6[Why the solution works]
L7[Additional technical contributions]
R1[Part 1 Task applications and target metrics]
R2[Part 2 SOTA methods failure and root issue]
R3[Part 3 Proposed solution and why it works]
R4[Part 4 Additional contributions and impact]
R5[Part 5 Experiments]
L1 --> L2
L2 --> L3
L3 --> L4
L4 --> L5
L5 --> L6
L6 --> L7
R1 --> R2
R2 --> R3
R3 --> R4
R4 --> R5
L1 --> R1
L2 --> R1
L3 --> R2
L4 --> R2
L5 --> R3
L6 --> R3
L7 --> R4
```
## How to Think About Introduction: Backward First, Then Forward
### Backward reasoning (answer these first)
1. What technical problem do we solve, and why is there no well-established solution? (important)
2. What are the contributions of our pipeline (e.g., a new valuable task, a new valuable metric, a new technical problem, or a new technique)?
3. What are the benefits of our contributions, why can they solve this technical challenge, and what new insight do they bring? (important)
4. How do we use prior methods to lead readers to our solved challenge and our new insight?
### Forward story (write in this order)
1. Introduce the paper's task.
2. Use prior methods to lead to the technical challenge we solve.
3. Present xx contributions to solve this technical challenge.
4. Explain technical advantages of our contributions and explicitly express our new insight. (important)
## Section Skeleton
```latex
\section{Introduction}
% Task and application
% Technical challenge for previous methods (discuss around the technical challenge that we solved. A technical challenge includes both limitation and technical reason)
% Introduce our pipeline for solving the challenge
% Experiment
% Contributions
```
## Part A: Introduce Task and Application
### Version 1
`Version 1: If the task is relatively niche, introduce the task first, then introduce applications.`
Writing structure:
1. Define the task in one clear sentence (`what output` from `what input`).
2. Briefly explain the task objective or scope (optional).
3. Introduce application value with 2-3 representative scenarios.
Sentence skeleton:
1. `[xxx task] targets at recovering/reconstructing/estimating [xxx output] from [xxx input].`
2. `[xxx task] has a variety of applications such as [xxx], [xxx], and [xxx].`
Local cite:
1. `references/examples/introduction/version-1-task-then-application.md`
### Version 2
`Version 2: If the task is already familiar to most readers, introduce applications directly.`
Writing structure:
1. Skip formal task definition.
2. Open with application importance in one concise sentence.
3. Optionally append target requirement (e.g., accuracy/efficiency/robustness).
Sentence skeleton:
1. `[xxx task] has a variety of applications such as [xxx], [xxx], and [xxx].`
Local cite:
1. `references/examples/introduction/version-2-application-first.md`
### Version 3
`Version 3: Introduce applications of the general task first, then introduce the specific task setting. (Personally recommended when the setting is relatively new.)`
Writing structure:
1. Start from the general task and why it matters.
2. Narrow down to the specific setting of this paper.
3. Clarify exact input/output and boundary of the setting.
Sentence skeleton:
1. `[general task] has a variety of applications such as [xxx], [xxx], and [xxx].`
2. `This paper focuses on the specific setting of recovering/reconstructing/estimating [xxx output] from [xxx input].`
Local cite:
1. `references/examples/introduction/version-3-general-to-specific-setting.md`
### Version 4
`Version 4: If the task is familiar, introduce applications directly and expose the target technical challenge in the opening paragraph via previous methods (failure cases / target metric improvements).`
Writing structure:
1. Start with task/application importance.
2. Immediately summarize how representative previous methods work.
3. Immediately expose the unresolved failure case + technical reason.
4. Use this opening as a bridge to the later prior-work paragraphs.
Opening-paragraph skeleton:
1. `[Task/application importance sentence].`
2. `Given input ..., previous methods usually ...`
3. `Although they work in many cases, they fail at ... because ...`
Expert note:
1. It is often good if the first paragraph already states what problem you want to solve, instead of requiring several paragraphs of prior work before the challenge appears.
2. This style needs the right conditions and is less common.
3. Typical Version 4 flow: Part 1 (task + application and directly expose challenge via previous methods 1) -> Part 2 (previous methods 2 try to solve it but still fail) -> Part 3 (our method).
4. More common general flow: Part 1 (task + application) -> Part 2 (previous methods 1 + limitation) -> Part 3 (previous methods 2 + limitation; here the target challenge emerges) -> Part 4 (our method).
Local cite:
1. `references/examples/introduction/version-4-open-with-challenge.md`
## Part B: Introduce Technical Challenge for Previous Methods (Very Important)
Purpose:
1. Discuss around the exact technical challenge we solved.
2. Build reader curiosity about how to solve this challenge.
3. Make motivation/benefit of our method clear.
Key logic before writing (faithful translation):
1. First make clear the logic for "leading to the technical challenge we solved".
2. For existing tasks: identify which recent methods have this challenge, why those methods exist, and optionally what earlier challenge they were trying to solve.
3. For novel tasks: at minimum, define the technical challenge solved by our pipeline.
Important warning :
1. Do not first present a naive solution and then describe our improvement over it.
2. That writing makes the work look like a low-score incremental patch.
3. Even if the work is actually incremental, do not write it this way.
4. Why: this writing style can erase reader curiosity and make the idea look straightforward only because the writing hand-holds the reader.
### Technical-Challenge Version 1 (existing task, with existing methods)
`Version 1: For existing tasks, discuss the challenge chain from general challenge -> traditional methods -> recent methods -> remaining challenge that we solve.`
Writing structure:
1. Start with a general challenge statement for this task.
2. Briefly summarize traditional methods and their limitation.
3. Briefly summarize recent methods (1) and their limitation with technical reason.
4. Briefly summarize recent methods (2) and their limitation with technical reason.
5. Ensure the final limitation is exactly the challenge your method solves.
Sentence skeleton:
1. `This problem is particularly challenging due to ...`
2. `To overcome these challenges, traditional methods ... However, they ...`
3. `Recently, ... methods ... However, they ... because ...`
4. `To overcome this challenge, ... methods ... However, they ... because ...`
Local cite:
1. `references/examples/introduction/technical-challenge-version-1-existing-task.md`
### Technical-Challenge Version 2 (existing task + our insight seen in traditional methods)
`Version 2: For existing tasks, when our insight has historical roots in traditional methods, use that line as conceptual backing and then show why new methods still fail.`
Writing structure:
1. Start from mainstream methods and state their limitation.
2. Introduce a classical/traditional line that already contains insight similar to yours.
3. Explain why that classical line is still insufficient.
4. Return to modern methods and show the unresolved technical reason.
5. Bridge to your method naturally.
Sentence skeleton:
1. `Traditional/recent methods ... However, they ... because ...`
2. `To overcome this problem, a typical approach is [insight], which has long been explored ...`
3. `However, these methods still ... because ...`
4. `To overcome this challenge, newer methods ... However, they ... because ...`
Local cite:
1. `references/examples/introduction/technical-challenge-version-2-existing-task-insight-backed-by-traditional.md`
### Technical-Challenge Version 3 (novel task, no direct methods)
`Version 3: For novel tasks without direct prior methods, define the challenge directly and decompose it into several concrete challenge points.`
Writing structure:
1. State the goal and explain that the problem is challenging for N reasons.
2. Use `First/Second/Finally` to separate independent challenge points.
3. For each point, state the observable limitation and the technical reason.
4. End with a transition to your pipeline.
Sentence skeleton:
1. `In this work, our goal is to ... This problem is challenging for three reasons.`
2. `First, ...`
3. `Second, ...`
4. `Finally, ...`
Local cite:
1. `references/examples/introduction/technical-challenge-version-3-novel-task.md`
## Part C: Introduce Our Pipeline for Solving the Challenge
Key questions before writing:
### For existing tasks
1. What technical challenge does our pipeline solve?
2. What is our technical contribution?
3. Why can our method work in essence?
4. What benefits does our method have over previous methods?
### For novel tasks
1. What technical challenge does our pipeline solve?
2. What is our technical contribution?
3. Why can our method work in essence?
### Pipeline Version 1
`Version 1: One contribution with multiple advantages, and one teaser figure to present the basic idea.`
Writing structure:
1. Introduce one core framework/representation for the target task.
2. Point to teaser figure for the basic idea.
3. State key novelty in one sentence.
4. Explain concrete implementation steps (`Specifically, ...`).
5. State multiple advantages (`In contrast ...`, `Another advantage ...`).
Sentence skeleton:
1. `In this paper, we propose a novel framework/representation, named ..., for ...`
2. `The basic idea is illustrated in Figure ...`
3. `Our innovation is in ...`
4. `Specifically, ...`
5. `In contrast to previous methods, ...`
6. `Another advantage of the proposed method is that ...`
Local cite:
1. `references/examples/introduction/pipeline-version-1-one-contribution-multi-advantages.md`
### Pipeline Version 2
`Version 2: Two contributions, and one teaser figure to present the basic idea.`
Writing structure:
1. Introduce framework and key novelty sentence.
2. Point to teaser figure.
3. Explain contribution 1 and its advantage.
4. Introduce a remaining challenge.
5. Explain contribution 2 as the response to that challenge.
Sentence skeleton:
1. `In this paper, we propose ...`
2. `Our innovation is in ...`
3. `The basic idea is illustrated in Figure ...`
4. `Specifically, ...` (contribution 1)
5. `In contrast to previous methods, ...`
6. `However, ...` (remaining challenge)
7. `Specifically, ...` (contribution 2)
Local cite:
1. `references/examples/introduction/pipeline-version-2-two-contributions.md`
### Pipeline Version 3
`Version 3: Build on a prior pipeline and introduce one new module, with a teaser figure for the basic idea.`
Writing structure:
1. Start from prior pipeline setup.
2. Introduce one new module as key innovation.
3. Provide an observation that motivates the module design.
4. Explain the module mechanism.
5. Compare against generic alternatives and state why it is better.
Sentence skeleton:
1. `Inspired by previous methods, ...`
2. `Our innovation is introducing ...`
3. `We observe that ...`
4. `Considering that ..., we introduce ...`
5. `In contrast to ..., our module ...`
Local cite:
1. `references/examples/introduction/pipeline-version-3-new-module-on-existing-pipeline.md`
### Pipeline Version 4
`Version 4: Contribution comes from one important observation. Introduce key innovation first, then a listener-friendly observation as motivation, then method details, then benefits.`
Writing structure:
1. State key innovation first.
2. State one intuitive observation as motivation.
3. Explain implementation details.
4. Explain technical advantage and empirical gain.
Sentence skeleton:
1. `Our innovation is ...`
2. `We observe that ...`
3. `Considering that ..., we ...`
4. `This leads to ... and achieves ...`
Local cite:
1. `references/examples/introduction/pipeline-version-4-observation-driven.md`
### Not Recommended Writing
`Not recommended: If the method is simple, do not hide concrete method design in Introduction and only describe abstract insights to make the work look novel.`
Expert note:
1. In this template, the writing craft is about making a simple pipeline sound novel.
2. The key caution: people often make the pipeline steps sound novel, not the real insight.
3. In most cases this is not recommended. The better target is to clearly explain core contribution implementation in Introduction.
Why not recommended (writing structure warning):
1. Presenting only abstract insight without concrete pipeline steps weakens technical clarity.
2. Introducing many new terms without mechanism-level explanation creates a novelty illusion.
3. Reviewers may interpret this as shallow or incremental work.
Local cite:
1. `references/examples/introduction/pipeline-not-recommended-abstract-only.md`
## Example Bank
1. `references/examples/introduction-examples.md`
2. `references/examples/introduction/version-1-task-then-application.md`
3. `references/examples/introduction/version-2-application-first.md`
4. `references/examples/introduction/version-3-general-to-specific-setting.md`
5. `references/examples/introduction/version-4-open-with-challenge.md`
6. `references/examples/introduction/technical-challenge-version-1-existing-task.md`
7. `references/examples/introduction/technical-challenge-version-2-existing-task-insight-backed-by-traditional.md`
8. `references/examples/introduction/technical-challenge-version-3-novel-task.md`
9. `references/examples/introduction/pipeline-version-1-one-contribution-multi-advantages.md`
10. `references/examples/introduction/pipeline-version-2-two-contributions.md`
11. `references/examples/introduction/pipeline-version-3-new-module-on-existing-pipeline.md`
12. `references/examples/introduction/pipeline-version-4-observation-driven.md`
13. `references/examples/introduction/pipeline-not-recommended-abstract-only.md`
## Quick Quality Checklist
1. Does the first sentence of each paragraph state its message?
2. Does each paragraph carry one message only?
3. Are technical challenge, technical reason, and solved mechanism all explicit?
4. Are claims in Introduction aligned with experiment evidence?
5. Is terminology stable across all sections?

View File

@@ -0,0 +1,196 @@
# Method Writing Guide
## Goal
Write the Method section clearly by following this sequence:
1. Answer key method-design questions.
2. Draw a pipeline figure sketch.
3. Write the method section step by step.
## Pre-Writing Questions
`Before writing Method, first answer: (1) what modules exist in the method, and (2) for each module, what is the workflow, why this module is needed, and why this module works.`
Recommended organization:
1. List all modules in the pipeline.
2. For each module, answer three questions:
- How does the module run?
- Why do we need this module?
- Why does this module work?
3. Organize answers as a mind map or a table for clarity.
## Method Writing Steps
`Method writing steps: (1) draw pipeline figure sketch, (2) map subsections from the sketch, (3) plan each subsection with motivation/design/advantages, (4) write module design first, (5) then add motivation and technical advantages.`
Step-by-step workflow:
1. Draw the pipeline figure sketch.
2. Use the sketch to organize Method subsection structure.
3. For each subsection, plan three parts: motivation, module design, and technical advantages.
4. Write module design first to build a concrete backbone.
5. Add motivation and technical advantages afterward.
## Three Elements of a Pipeline Module
`A pipeline module has three elements: Module design, Motivation of this module, and Technical advantages of this module.`
### 1) Module Design
Definition:
1. Describe representation/network/data-structure details.
2. Describe the forward process clearly: given input -> step 1 -> step 2 -> step 3 -> output.
### 2) Motivation of This Module
Definition:
1. Explain why this module is needed.
2. Use problem-driven logic: because problem X exists, we design module Y.
### 3) Technical Advantages of This Module
Definition:
1. Explain why this module has technical advantage over alternatives.
2. Tie advantage to measurable behavior when possible.
### Example of the Three Elements
Local cite:
1. `references/examples/method/example-of-the-three-elements.md`
## Method Content Decomposition
```mermaid
flowchart LR
A["Draw the technical pipeline figure"] --> B["Decompose Method content"]
B --> C1["Subsection 1 (Technical Module 1)"]
B --> C2["Subsection 2 (Technical Module 2)"]
B --> C3["Subsection 3 (Technical Module 3)"]
C1 --> D1["Motivation"]
C1 --> D2["Detailed design"]
C1 --> D3["Technical advantage"]
```
## How to Write Module Design
`Module design usually has two parts: (1) describe specific data/network structures, and (2) describe forward process as input -> steps -> output.`
Writing structure:
1. Define key structures first (representation, network, data structure).
2. Write forward process in strict execution order.
3. End with output interpretation or purpose.
Sentence skeleton:
1. `We represent ... with ...`
2. `Given [input], we first ... then ... finally ...`
3. `This produces [output], which is used for ...`
Local cite:
1. `references/examples/method/module-design-instant-ngp.md`
## How to Write Module Motivation
`Module motivation is usually problem-driven: because a problem exists, we design xx to solve it.`
Typical opening sentences:
1. `A remaining problem/challenge is ...`
2. `However, we ...`
3. `Previous methods have difficulty in ...`
Local cite:
1. `references/examples/method/module-motivation-patterns.md`
## How to Check Whether Method is Easy to Understand
`Check method clarity from three levels: writing logic, paragraph writing, and sentence writing.`
### 1) Logic-level check
1. After finishing the paper, summarize the Method writing logic again.
2. Check whether this summarized logic is smooth and easy to follow.
### 2) Paragraph-level check
1. The first sentence of each paragraph should make readers immediately understand what this paragraph is about.
2. One paragraph should clearly deliver one message.
### 3) Sentence-level check
1. Carefully check whether the **motivation** of each sentence is explicit. Keep one thing clear to readers at all times: **why this sentence content is needed**.
2. Carefully check sentence-to-sentence flow.
3. Carefully check term consistency and avoid changing key terms back and forth.
## Method Section Skeleton
```latex
\section{Method}
% Overview
% Section 3.1
% Section 3.2
% Section 3.3
```
Local cite:
1. `references/examples/method/section-skeleton.md`
## Overview Subsection
`Overview should usually include: setting, core contribution, optional pipeline figure pointer, and a map of what each subsection contains.`
Writing structure:
1. One to two sentences for task setting.
2. One to two sentences for core contribution.
3. If pipeline/framework is novel, point to overview figure.
4. Tell readers what Section 3.1/3.2/3.3 covers.
Local cite:
1. `references/examples/method/overview-template.md`
## Section 3.1 and Other Module Subsections
`Basic subsection logic: (1) motivation of this module, (2) module forward process/module design, (3) technical advantages of this module.`
Local cite:
1. `references/examples/method/example-of-the-three-elements.md`
## Module Writing Pattern (Mermaid)
```mermaid
flowchart TB
M1["State module motivation (challenge)"] --> M2["Define module design (representation/network)"]
M2 --> M3["Describe forward process (input -> steps -> output)"]
M3 --> M4["Explain technical advantages and verifiable gains"]
```
## Implementation Details
`Implementation details include hyperparameters (e.g., layer count, feature dimensions), coordinate transforms/normalization, and other practical details. Put them near the end of Method or in a dedicated Implementation Details section.`
## Example Bank
1. `references/examples/method-examples.md`
2. `references/examples/method/pre-writing-questions.md`
3. `references/examples/method/module-triad-neural-body.md`
4. `references/examples/method/module-design-instant-ngp.md`
5. `references/examples/method/module-motivation-patterns.md`
6. `references/examples/method/section-skeleton.md`
7. `references/examples/method/overview-template.md`
8. `references/examples/method/example-of-the-three-elements.md`
9. `references/examples/method/method-writing-common-issues-note.md`

View File

@@ -0,0 +1,86 @@
# Paper Review
## Goal
Use an adversarial, reviewer-style checklist to detect reject risks early and revise the paper before submission.
## Core Principle
Pursue perfectionism in paper quality: assume reviewers will probe every weak point and proactively fix them.
## Critical Rule (Do Not Violate)
Every major claim, especially in Abstract and Introduction, must be:
1. technically correct, and
2. explicitly supported by experimental evidence.
If a claim is not supported, either add evidence or weaken/remove the claim.
## What Usually Gets a Paper Accepted
1. Sufficient contribution (for example: novel task, novel pipeline, novel module, novel design choices, new experimental findings, or new insight).
2. Better empirical performance than prior methods under fair comparisons.
3. Sufficient comparison experiments and ablation studies.
## Common Rejection Dimensions
| Rejection Dimension | Typical Failure Signals |
| ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| 1. Insufficient contribution | 1.1 Targeted failure cases are too common.<br /> 1.2 Proposed technique is already well explored; expected gains are predictable/well-known. |
| 2. Unclear writing | 2.1 Missing technical details; work is not reproducible.<br />2.2 A method module lacks clear motivation. |
| 3. Weak empirical effect | 3.1 Improvement over prior methods is only marginal.<br /> 3.2 Even if better than previous methods, absolute performance is still not strong enough. |
| 4. Incomplete evaluation | 4.1 Missing ablation studies.<br />4.2 Missing important baselines or important evaluation metrics.<br /> 4.3 Datasets are too simple to prove the method truly works. |
| 5. Problematic method design | 5.1 Experimental setting is unrealistic.<br />5.2 Method has technical flaws and appears unreasonable.<br />5.3 Method is not robust and needs per-scenario hyperparameter tuning. <br /> 5.4 New design introduces stronger limitations than its benefits, leading to negative net value. |
## End-of-Paper Self-Review Question List
Add this checklist near the end of the draft while revising.
Use each question to trigger concrete edits before submission.
### 1. Contribution
1. What new knowledge does this paper give to readers?
2. Are we solving a truly meaningful failure case, not a trivial/common one?
3. Is the technical idea genuinely non-obvious beyond well-explored practice?
4. Is our gain surprising or insightful rather than a predictable improvement?
5. Is there at least one clear novelty type (task/pipeline/module/design finding/insight)?
### 2. Writing Clarity
1. Can a knowledgeable reader reproduce the method from the paper?
2. Did we provide enough technical detail for each key module?
3. Is the motivation of every module explicit and logically connected to a challenge?
4. Are terms and notation consistent across sections?
5. Does each paragraph carry one clear message with smooth transitions?
### 3. Experimental Strength
1. Are improvements over strong baselines meaningful, not just statistically tiny?
2. Is absolute performance competitive enough for the target venue?
3. Are gains consistent across multiple datasets/settings/metrics?
4. Do we report both strengths and failure cases honestly?
### 4. Evaluation Completeness
1. Do we include ablations for all key design choices?
2. Are all strong/recent baselines included under fair settings?
3. Are evaluation metrics standard and sufficient for this task?
4. Are datasets/scenarios challenging enough to validate real effectiveness?
5. Are comparison and ablation protocols clearly documented?
### 5. Method Design Soundness
1. Is the experimental setting realistic for practical use?
2. Does the method have hidden technical defects or unreasonable assumptions?
3. Is the method robust without heavy per-case hyperparameter retuning?
4. Do benefits outweigh added complexity and new limitations?
5. Could reviewers reasonably argue that the net benefit is negative?
## Adversarial Writing Workflow
1. Read the paper as a skeptical reviewer.
2. Answer every question above with explicit evidence from the paper.
3. Mark each item as `pass`, `needs revision`, or `needs new experiment`.
4. Revise claims, writing, experiments, or method scope accordingly.
5. Repeat until no major rejection risk remains.

View File

@@ -0,0 +1,46 @@
# Paragraph Flow
Use this reference when the user asks whether a paragraph flows, makes sense, or
is clear.
## Core principle
Flow is not decoration. A paragraph flows when an external reader can identify:
- the paragraph's single message
- how the first sentence announces that message
- how each following sentence relates to the previous one
- how the paragraph supports the section thesis
## Reader test
Read as a skeptical but fair external reader:
1. Does the paragraph have one explicit message?
2. Does the first sentence state what the paragraph is doing?
3. Are all key nouns, terms and abbreviations readable without hidden context?
4. Does each sentence connect by cause, contrast, consequence, refinement, or example?
5. Is any sentence carrying material that belongs in another paragraph?
## Reverse outlining
For a section-level flow check:
1. Write down the section thesis or main claim.
2. Write down each paragraph's topic sentence.
3. Write down the evidence or explanation under each paragraph.
4. Check `topic sentence -> section thesis`.
5. Check `evidence -> topic sentence`.
6. Revise or remove any paragraph that cannot be mapped cleanly.
If reverse outlining is hard, the section probably has a hidden structure problem.
## Repair moves
- Split paragraphs that contain two messages.
- Move definitions before terms are reused.
- Replace vague transitions with explicit relations such as `therefore`,
`however`, `by contrast`, `for example`, or `as a result`.
- Add temporary subsection labels during revision, then remove labels that are
not needed in the final manuscript.
- Keep paragraph openings claim-first unless the section needs a brief setup.

View File

@@ -0,0 +1,41 @@
# Related Work Writing Guide
## Goal
Position your work against the most relevant lines of research, and make your novelty easy to verify.
## Workflow
1. List directly competing and recent baseline papers first.
2. Group literature by technical topic (not by publication year alone).
3. For each topic: summarize common paradigm, then key limitation relevant to your challenge.
4. End each topic by clarifying your distinction.
## Topic Design
Use 2-4 focused topics, for example:
1. Task-specific mainstream methods.
2. Methods closest to your core idea.
3. Auxiliary techniques your method builds on.
## Paragraph Template
1. Topic sentence: define scope of this topic.
2. Representative methods: one compact summary.
3. Limitation tied to your target technical challenge.
4. Transition sentence that leads to your method.
## Do and Don't
1. Do compare mechanisms, assumptions, and failure modes.
2. Do emphasize the exact gap your method fills.
3. Do not make Related Work a citation dump.
4. Do not hide strongest baselines.
## Checklist
1. Are all strongest/recent competitors covered?
2. Is each topic connected to your problem setting?
3. Is your difference explained in technical terms, not marketing terms?
4. Is citation coverage complete for all core claims?