glen/dyna3
1
0
Fork 0
Code Issues 11 Pull Requests 1 Actions Projects Releases 2 Wiki Activity

Integrate engine into application prototype #15

Merged
glen merged 24 commits from engine-integration into main 2024-11-12 00:46:16 +00:00
Conversation 15 Commits 24 Files Changed 14 +22 -20
4 changed files with 22 additions and 20 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files
Showing only changes of commit da008fd090 - Show all commits

28
app-proto/src/add_remove.rs
View File

@ -11,7 +11,7 @@ fn load_gen_assemb(assembly: &Assembly) {
id: String::from("gemini_a"),
label: String::from("Castor"),
color: [1.00_f32, 0.25_f32, 0.00_f32],
rep: engine::sphere(0.5, 0.5, 0.0, 1.0),
representation: engine::sphere(0.5, 0.5, 0.0, 1.0),
constraints: BTreeSet::default(),
index: 0
}
@ -21,7 +21,7 @@ fn load_gen_assemb(assembly: &Assembly) {
id: String::from("gemini_b"),
label: String::from("Pollux"),
color: [0.00_f32, 0.25_f32, 1.00_f32],
rep: engine::sphere(-0.5, -0.5, 0.0, 1.0),
representation: engine::sphere(-0.5, -0.5, 0.0, 1.0),
constraints: BTreeSet::default(),
index: 0
}
@ -31,7 +31,7 @@ fn load_gen_assemb(assembly: &Assembly) {
id: String::from("ursa_major"),
label: String::from("Ursa major"),
color: [0.25_f32, 0.00_f32, 1.00_f32],
rep: engine::sphere(-0.5, 0.5, 0.0, 0.75),
representation: engine::sphere(-0.5, 0.5, 0.0, 0.75),
constraints: BTreeSet::default(),
index: 0
}
@ -41,7 +41,7 @@ fn load_gen_assemb(assembly: &Assembly) {
id: String::from("ursa_minor"),
label: String::from("Ursa minor"),
color: [0.25_f32, 1.00_f32, 0.00_f32],
rep: engine::sphere(0.5, -0.5, 0.0, 0.5),
representation: engine::sphere(0.5, -0.5, 0.0, 0.5),
constraints: BTreeSet::default(),
index: 0
}
@ -51,7 +51,7 @@ fn load_gen_assemb(assembly: &Assembly) {
id: String::from("moon_deimos"),
label: String::from("Deimos"),
color: [0.75_f32, 0.75_f32, 0.00_f32],
rep: engine::sphere(0.0, 0.15, 1.0, 0.25),
representation: engine::sphere(0.0, 0.15, 1.0, 0.25),
constraints: BTreeSet::default(),
index: 0
}
@ -61,7 +61,7 @@ fn load_gen_assemb(assembly: &Assembly) {
id: String::from("moon_phobos"),
label: String::from("Phobos"),
color: [0.00_f32, 0.75_f32, 0.50_f32],
rep: engine::sphere(0.0, -0.15, -1.0, 0.25),
representation: engine::sphere(0.0, -0.15, -1.0, 0.25),
constraints: BTreeSet::default(),
index: 0
}
@ -76,7 +76,7 @@ fn load_low_curv_assemb(assembly: &Assembly) {
id: "central".to_string(),
label: "Central".to_string(),
color: [0.75_f32, 0.75_f32, 0.75_f32],
rep: engine::sphere(0.0, 0.0, 0.0, 1.0),
representation: engine::sphere(0.0, 0.0, 0.0, 1.0),
constraints: BTreeSet::default(),
index: 0
}
@ -86,7 +86,7 @@ fn load_low_curv_assemb(assembly: &Assembly) {
id: "assemb_plane".to_string(),
label: "Assembly plane".to_string(),
color: [0.75_f32, 0.75_f32, 0.75_f32],
rep: engine::sphere_with_offset(0.0, 0.0, 1.0, 0.0, 0.0),
representation: engine::sphere_with_offset(0.0, 0.0, 1.0, 0.0, 0.0),
constraints: BTreeSet::default(),
index: 0
}
@ -96,7 +96,7 @@ fn load_low_curv_assemb(assembly: &Assembly) {
id: "side1".to_string(),
label: "Side 1".to_string(),
color: [1.00_f32, 0.00_f32, 0.25_f32],
rep: engine::sphere_with_offset(1.0, 0.0, 0.0, 1.0, 0.0),
representation: engine::sphere_with_offset(1.0, 0.0, 0.0, 1.0, 0.0),
constraints: BTreeSet::default(),
index: 0
}
@ -106,7 +106,7 @@ fn load_low_curv_assemb(assembly: &Assembly) {
id: "side2".to_string(),
label: "Side 2".to_string(),
color: [0.25_f32, 1.00_f32, 0.00_f32],
rep: engine::sphere_with_offset(-0.5, a, 0.0, 1.0, 0.0),
representation: engine::sphere_with_offset(-0.5, a, 0.0, 1.0, 0.0),
constraints: BTreeSet::default(),
index: 0
}
@ -116,7 +116,7 @@ fn load_low_curv_assemb(assembly: &Assembly) {
id: "side3".to_string(),
label: "Side 3".to_string(),
color: [0.00_f32, 0.25_f32, 1.00_f32],
rep: engine::sphere_with_offset(-0.5, -a, 0.0, 1.0, 0.0),
representation: engine::sphere_with_offset(-0.5, -a, 0.0, 1.0, 0.0),
constraints: BTreeSet::default(),
index: 0
}
@ -126,7 +126,7 @@ fn load_low_curv_assemb(assembly: &Assembly) {
id: "corner1".to_string(),
label: "Corner 1".to_string(),
color: [0.75_f32, 0.75_f32, 0.75_f32],
rep: engine::sphere(-4.0/3.0, 0.0, 0.0, 1.0/3.0),
representation: engine::sphere(-4.0/3.0, 0.0, 0.0, 1.0/3.0),
constraints: BTreeSet::default(),
index: 0
}
@ -136,7 +136,7 @@ fn load_low_curv_assemb(assembly: &Assembly) {
id: "corner2".to_string(),
label: "Corner 2".to_string(),
color: [0.75_f32, 0.75_f32, 0.75_f32],
rep: engine::sphere(2.0/3.0, -4.0/3.0 * a, 0.0, 1.0/3.0),
representation: engine::sphere(2.0/3.0, -4.0/3.0 * a, 0.0, 1.0/3.0),
constraints: BTreeSet::default(),
index: 0
}
@ -146,7 +146,7 @@ fn load_low_curv_assemb(assembly: &Assembly) {
id: String::from("corner3"),
label: String::from("Corner 3"),
color: [0.75_f32, 0.75_f32, 0.75_f32],
rep: engine::sphere(2.0/3.0, 4.0/3.0 * a, 0.0, 1.0/3.0),
representation: engine::sphere(2.0/3.0, 4.0/3.0 * a, 0.0, 1.0/3.0),
constraints: BTreeSet::default(),
index: 0
}

8
app-proto/src/assembly.rs
View File

@ -12,7 +12,7 @@ pub struct Element {
pub id: String,
pub label: String,
pub color: [f32; 3],
glen marked this conversation as resolved Outdated
glen commented 2024-11-09 23:59:52 +00:00
Outdated
Review
Copy Link

Shouldn't we have at least a typedef somewhere for color representations, in case we use a different color space at some point? For example, we are almost certain to want to add an opacity level to our colors. (Certainly the final product will allow you to set the opacity of any element.)

Shouldn't we have at least a typedef somewhere for color representations, in case we use a different color space at some point? For example, we are almost certain to want to add an opacity level to our colors. (Certainly the final product will allow you to set the opacity of any element.)
👍 1
Vectornaut commented 2024-11-11 08:06:01 +00:00
Outdated
Review
Copy Link

Done, with the type alias ElementColor.

Done, with the type alias `ElementColor`.
glen commented 2024-11-11 15:54:05 +00:00
Outdated
Review
Copy Link

OK, we will use that for now; the name implies we might have a different type for the color of something else, like the axes in a view (which aren't part of the Assembly). If we do start using this type for the colors of other things, we should rename it, I think.

OK, we will use that for now; the name implies we might have a different type for the color of something else, like the axes in a view (which aren't part of the Assembly). If we do start using this type for the colors of other things, we should rename it, I think.
pub rep: DVector<f64>,
pub representation: DVector<f64>,
glen marked this conversation as resolved Outdated
glen commented 2024-11-09 23:57:26 +00:00
Outdated
Review
Copy Link

Same comments go for rep here as in Constraint. Maybe it's "representative"? If your worry is that a full word will be too long, look for a shorter word, or pick a unique short acronym for this sort of thing in both places, and then clearly document what that acronym means and why you are using it. Maybe for now "document" just means "comment" until we have a decent doc system in place.

Same comments go for rep here as in Constraint. Maybe it's "representative"? If your worry is that a full word will be too long, look for a shorter word, or pick a unique short acronym for this sort of thing in both places, and then clearly document what that acronym means and why you are using it. Maybe for now "document" just means "comment" until we have a decent doc system in place.
Vectornaut commented 2024-11-11 03:29:35 +00:00
Outdated
Review
Copy Link

Same comments go for rep here as in Constraint. Maybe it's "representative"?

It's for "representation"—a vector representation of the element, acted on by a linear representation of the 3d Möbius group. When I update the PR, I'll expand the property name to representation (in commit da008fd).

> Same comments go for rep here as in Constraint. Maybe it's "representative"? It's for "representation"—a vector representation of the element, acted on by a linear representation of the 3d Möbius group. When I update the PR, I'll expand the property name to `representation` (in commit da008fd).
glen commented 2024-11-11 19:57:27 +00:00
Outdated
Review
Copy Link

One other comment: some of the stuff in the assembly is intrinsic, i.e. there is a red sphere, constrained to have radius 1, containing a point with id A labeled A_{init}, say. Other stuff is contingent: the current realization of the red sphere has such-and-such representation, and point id A is selected. (I think the selection needs to be constant and shared across all views, so may as well be in the Assembly.) There may turn out to be practical reasons to separate those types of things in some way, but I certainly think there are conceptual advantages to doing so. For now, we may just want to keep in mind to choose names that suggest the intrinsic/contingent divide. It may be that "representation" is sufficiently suggestive in this way, or perhaps a name like "realization" would be better, and "currentRealization" is even stronger in this regard. Similarly, "selection" might already feel contingent enough; "currentlySelected" certainly would. This is not a request for any particular change to the current PR, just an item to keep in mind, although if you are moved to make any changes that's OK too.

One other comment: some of the stuff in the assembly is intrinsic, i.e. there _is_ a red sphere, constrained to have radius 1, containing a point with id A labeled `A_{init}`, say. Other stuff is contingent: the current realization of the red sphere has such-and-such representation, and point id A is selected. (I think the selection needs to be constant and shared across all views, so may as well be in the Assembly.) There may turn out to be practical reasons to separate those types of things in some way, but I certainly think there are conceptual advantages to doing so. For now, we may just want to keep in mind to choose names that suggest the intrinsic/contingent divide. It may be that "representation" is sufficiently suggestive in this way, or perhaps a name like "realization" would be better, and "currentRealization" is even stronger in this regard. Similarly, "selection" might already feel contingent enough; "currentlySelected" certainly would. This is not a request for any particular change to the current PR, just an item to keep in mind, although if you are moved to make any changes that's OK too.
pub constraints: BTreeSet<usize>,
// internal properties, not reflected in any view
@ -86,7 +86,7 @@ impl Assembly {
id: id,
label: format!("Sphere {}", id_num),
color: [0.75_f32, 0.75_f32, 0.75_f32],
rep: DVector::<f64>::from_column_slice(&[0.0, 0.0, 0.0, 0.5, -0.5]),
representation: DVector::<f64>::from_column_slice(&[0.0, 0.0, 0.0, 0.5, -0.5]),
constraints: BTreeSet::default(),
index: 0
glen marked this conversation as resolved Outdated
glen commented 2024-11-10 00:32:03 +00:00
Outdated
Review
Copy Link

I am very confused by index: 0. I guess I was wrong that the index is a quick way to get at the element within the assembly? Maybe this will all be clear once the naming of types and properties is a bit improved, but if not, please comment this line.

I am very confused by `index: 0`. I guess I was wrong that the index is a quick way to get at the element within the assembly? Maybe this will all be clear once the naming of types and properties is a bit improved, but if not, please comment this line.
👍 1
Vectornaut commented 2024-11-11 05:08:27 +00:00
Outdated
Review
Copy Link

The PR update will add a comment that explains the index field's meaning, as described in this comment, and reminds us to make index private when that becomes possible (for example, in pull request #16).

The PR update will add a comment that explains the `index` field's meaning, as described in [this comment](https://code.studioinfinity.org/glen/dyna3/pulls/15#issuecomment-1816), and reminds us to make `index` private when that becomes possible (for example, in pull request #16).
glen commented 2024-11-11 16:14:17 +00:00
Outdated
Review
Copy Link

Great. And please add to #16 to rename this property to something that has "column" in it -- that's much more informative than index, which could be an index into anything.

Great. And please add to #16 to rename this property to something that has "column" in it -- that's much more informative than index, which could be an index into anything.
}
@ -133,7 +133,7 @@ impl Assembly {
for (_, elt) in elts {
let index = elt.index;
gram_to_be.push_sym(index, index, 1.0);
guess_to_be.set_column(index, &elt.rep);
guess_to_be.set_column(index, &elt.representation);
}
(gram_to_be, guess_to_be)
@ -177,7 +177,7 @@ impl Assembly {
// read out the solution
self.elements.update(|elts| {
for (_, elt) in elts.iter_mut() {
elt.rep.set_column(0, &config.column(elt.index));
elt.representation.set_column(0, &config.column(elt.index));
}
});
}

4
app-proto/src/display.rs
View File

@ -297,7 +297,9 @@ pub fn Display() -> View {
// get the assembly
let elements = state.assembly.elements.get_clone();
let element_iter = (&elements).into_iter();
let reps_world: Vec<_> = element_iter.clone().map(|(_, elt)| &assembly_to_world * &elt.rep).collect();
let reps_world: Vec<_> = element_iter.clone().map(
|(_, elt)| &assembly_to_world * &elt.representation
).collect();
let colors: Vec<_> = element_iter.clone().map(|(key, elt)|
if state.selection.with(|sel| sel.contains(&key)) {
elt.color.map(|ch| 0.2 + 0.8*ch)

2
app-proto/src/outline.rs
View File

@ -72,7 +72,7 @@ pub fn Outline() -> View {
}
});
let label = elt.label.clone();
let rep_components = elt.rep.iter().map(|u| {
let rep_components = elt.representation.iter().map(|u| {
let u_coord = u.to_string().replace("-", "\u{2212}");
View::from(div().children(u_coord))
}).collect::<Vec<_>>();