Auto instancing #150

vitvakatu · Dec 9, 2017

fixes #37

Q&A:

Insanity?

No, just auto instancing support. (I'm lying, it's crazy)

What have you done?

Short list:

All shaders were modified - no more Locals, just vertex attributes.
Material enum was renamed to MaterialType, made private, added new Material struct.
Why? Because I need UIDs to group meshes in renderer.
Huge refactoring in the render module in order to reduce code duplication for both instanced and regular rendering.
mesh_instance* was renamed to duplicate_mesh*. Reason - you can't change material for mesh with instancing support. (Well, actually you can, but you will lose optimization. Perhaps I should keep this method?)

Worth it?

Totally! In group example, performance have increased from 14 to stable 60 FPS (in release mode).

Some things looks really weird, so ask me please.
Renderer now looks like a total mess, but I would like to continue my work on it.

alteous · Dec 9, 2017

Holy crap this is impressive! Totally worth the wait. :)

kvark · Dec 11, 2017

Reason - you can't change material for mesh with instancing support. (Well, actually you can, but you will lose optimization. Perhaps I should keep this method?)

I'd prefer the original method. Let's define the optimizations to be at the implementation discretion. I.e. user should still be able to change the material properties (as opposed to changing to a different material entirely) without the loss of optimization.

kvark · Dec 11, 2017

kvark reviewed Dec 11, 2017

View changes

Amazing work, @vitvakatu !
I bet you gained a level or two in code building and render engineering ;)

Aside from the mentioned concerns, my biggest one is: can we get away without atomic IDs on geometry and material? Could you explain in detail on why those are needed?

kvark · Dec 11, 2017

data/shaders/basic_vs.glsl

+in vec4 a_World0;
+in vec4 a_World1;
+in vec4 a_World2;
+in vec4 a_World3;


TODO: fit the world matrix into 3 vectors

kvark · Dec 11, 2017

data/shaders/basic_vs.glsl

 #include <globals>

 in vec4 a_Position;
 in vec4 a_Normal;
 in vec2 a_TexCoord;
 out vec2 v_TexCoord;
+out vec4 v_Color;
+
+in vec4 a_World0;


how about adopting a different prefix for the instance variables? say, i_XXX.

I'm not familiar with naming conventions in shaders so yes, will do

kvark · Dec 11, 2017

examples/group.rs

-    1.9,
-    //-2.2, //TODO when performance allows
-];
+const SPEEDS: [f32; 6] = [0.7, -1.0, 1.3, -1.6, 1.9, -2.2];


kvark · Dec 11, 2017

src/factory/mod.rs

        &mut self,
        template: &Mesh,
        material: M,
    ) -> Mesh {
        let mut hub = self.hub.lock().unwrap();
+        let instances = self.backend


might want to have a helper private method in the factory for this, given how many times it's repeated

kvark · Dec 11, 2017

src/geometry.rs

@@ -70,6 +73,7 @@ pub struct Geometry {
    pub shapes: HashMap<String, Shape>,
    /// Faces.
    pub faces: Vec<[u32; 3]>,
+    #[doc(hidden)] pub __id: usize,


does it have to be public?

Unfortunately :( You can't use nice .. Default::default() syntax on structs with private fields

kvark · Dec 11, 2017

src/mesh.rs

+    ///
+    /// It will improve performance in case of multiple `Mesh`es with the same
+    /// materials and geometries.
+    pub fn use_instancing(


I'd like us to not have this explicit switch, preferably. We can technically draw everything with instancing. Whatever happens to never be instanced will just have an instance of 1. Whatever does get instanced with instance_mesh should be automatically fast.

kvark · Dec 11, 2017

src/render/mod.rs

@@ -434,19 +466,29 @@ impl Renderer {
        let quad_buf = gl_factory.create_constant_buffer(1);
        let light_buf = gl_factory.create_constant_buffer(MAX_LIGHTS);
        let pbr_buf = gl_factory.create_constant_buffer(1);
+        let inst_buf = gl_factory
+            .create_buffer(
+                INSTANCE_COUNT,


instead of keeping around a fixed-inst-count buffer, I think we should have an automatically grown instance buffer per shader. We collect CPU instances first, then see if the buffer needs to be re-allocated (and do this), then fill out instance data.

If so, we need to store factory inside Renderer. Can't remember whether it's possible (probably yes)

kvark · Dec 11, 2017

src/render/mod.rs

@@ -953,6 +939,109 @@ impl Renderer {
        self.encoder.flush(&mut self.device);
    }

+    #[inline]
+    fn instance_basic(


maybe have those constructors inside impl Instance?

yes, it'd be better

vitvakatu · Dec 11, 2017

About IDs: you need to group meshes with same geometry and material in renderer. But both geometry and material structs are unhashable (and you can't do them hashable without some unique field). Maybe there's another solution?

vitvakatu · Dec 15, 2017

Okay, all concerns from @kvark were covered. Awaiting further review

kvark · Dec 15, 2017

kvark reviewed Dec 15, 2017

View changes

Neat! Looks like we are getting there :)
Great work, and a few more fixes are needed.

kvark · Dec 15, 2017

data/shaders/basic_vs.glsl

 #include <globals>

 in vec4 a_Position;
 in vec4 a_Normal;
 in vec2 a_TexCoord;
 out vec2 v_TexCoord;
+out vec4 v_Color;
+
+in vec4 i_World0;


would it make sense to move those instance inputs into a header ("locals")? hint: it will not if different shaders have different instance inputs

Well, most of the shaders use it, so I'll move it in header.

The instance variables are likely to change, so I'd say not.

kvark · Dec 15, 2017

data/shaders/basic_vs.glsl

+in vec4 i_World0;
+in vec4 i_World1;
+in vec4 i_World2;
+in vec4 i_World3;


as I mentioned before (and I don't think there was any reply?), we should use 3 vectors instead of 4 for the world transformation.

kvark · Dec 15, 2017

src/material.rs

+#[derive(Debug, Clone, PartialEq)]
+pub struct Material {
+    pub(crate) mat_type: MaterialType,
+    pub(crate) id: usize,


can we just hash the material instead of introducing the ID?

No, we can't. Materials contains f32s, that are unhashable. Even if we can find a way around it, our Texture<[f32; 4]> is unhashable too because of f32 again.

f32 in general are unhashable, but only because of the exceptions like de-normalized floats and NaN, Inf, etc. We can safely assume the f32 in the material are not exceptional (and abort otherwise). Hashing can't be derived automatically, but it can be implemented using one of the following methods:

just hashing raw 32bits of the float

if the float is known to be in a rage (say, 0-1), quantitize it with enough precision (u32 is more than enough).

Texture<[f32; 4]> is just a handle, once again, that is hashable. Caveat: we need to investigate in depth the safety of hashing the gfx handles, but for now this is an acceptable choice.

kvark · Dec 15, 2017

src/render/mod.rs

+        color: u32,
+        uv_range: [f32; 4],
+        param: f32,
+    ) -> Instance {


nit: Self

kvark · Dec 15, 2017

src/render/mod.rs

    pub pending: Option<DynamicData>,
+    pub use_instancing: bool,
+    pub instance_cache_key: InstanceCacheKey,


could we have Option<InstanceCacheKey> for clearer semantics than a separate boolean flag?

kvark · Dec 15, 2017

src/render/mod.rs

+
+        let slice = if instances.len() > 1 {
+            let mut slice = slice;
+            slice.instances = Some((instances.len() as u32, 0));


oh my, so many slice things!
could do Slice { instances: <something>, ..slice }

kvark · Dec 15, 2017

src/render/pso_data.rs

+#[derive(Clone, Debug)]
+pub(crate) struct PbrMapParams {
+    pub(crate) base_color: (
+        h::ShaderResourceView<BackendResources, [f32; 4]>,


let's have a type for shader view + sampler, given that we need it many times here

alteous · Dec 19, 2017

alteous reviewed Dec 19, 2017

View changes

alteous · Dec 19, 2017

src/material.rs

@@ -54,6 +62,8 @@ pub mod basic {
 }

 /// Parameters for a Lamberian diffusion reflection model.
+///
+/// Renders triangle meshes with the Gouraud illumination model.


*Lambertian illumination model.

Gouraud shading refers to whether lighting computed at the vertices of a polygon are interpolated across the face, hence the flat field disables/enables Gouraud shading.

I considered once having an enum Shading { Flat, Gouraud } but that felt a bit overkill.

Sure, I've been moving doc lines forth and back, so it's not the last change.

alteous · Dec 19, 2017

alteous reviewed Dec 19, 2017

View changes

alteous · Dec 19, 2017

src/render/mod.rs

+            MaterialType::Lambert(_) => &self.mesh_gouraud,
+            MaterialType::Phong(_) => &self.mesh_phong,
+            MaterialType::Sprite(_) => &self.sprite,
+            _ => unreachable!(),


Is it really unreachable or just an internal error if we hit this branch?

Unreachable for sure (if somebody won't break the renderer logic).

alteous · Dec 19, 2017

alteous approved these changes Dec 19, 2017

View changes

Awesome!

kvark · Dec 24, 2017

kvark approved these changes Dec 24, 2017

View changes

Looks good! Anything else baking in the oven?

vitvakatu · Dec 25, 2017

Yep, a few more things - safe wrappers around floats and grouping world matrix in 3 vectors.

alteous · Jan 1, 2018

alteous reviewed Jan 1, 2018

View changes

alteous · Jan 1, 2018

src/safe_float.rs

+impl Hash for SafeFloat {
+	fn hash<H: Hasher>(&self, state: &mut H) {
+        let mut buf = [0; 4];
+        LittleEndian::write_f32(&mut buf, self.0);


let's use an even better thing: https://doc.rust-lang.org/stable/std/primitive.f32.html#method.to_bits

kvark · Jan 2, 2018

Still WIP?

vitvakatu · Jan 2, 2018

Still WIP :(
Needs one last thing - correct Hash implementation for Custom material.

kvark · Jan 2, 2018

kvark requested changes Jan 2, 2018

View changes

kvark · Jan 2, 2018

src/render/mod.rs

@@ -786,6 +786,7 @@ impl Renderer {
            };

            let mx_world: [[f32; 4]; 4] = Matrix4::from(node.world_transform).into();
+            println!("{:?}", mx_world);


debug leftover

kvark · Jan 2, 2018

src/safe_float.rs

+pub struct SafeFloat(f32);
+
+impl SafeFloat {
+	pub fn try_from(value: f32) -> Option<Self> {


indentation is screwed up

kvark · Jan 2, 2018

src/safe_float.rs

+impl Hash for SafeFloat {
+	fn hash<H: Hasher>(&self, state: &mut H) {
+        let mut buf = [0; 4];
+        LittleEndian::write_f32(&mut buf, self.0);


let's use an even better thing: https://doc.rust-lang.org/stable/std/primitive.f32.html#method.to_bits

alteous · Jan 2, 2018

alteous reviewed Jan 2, 2018

View changes

alteous · Jan 2, 2018

src/material.rs

@@ -182,7 +212,45 @@ impl Default for Pbr {
    }
 }

+#[doc(hidden)]


pub(crate)?

No, can't expose private types in public enum Material

Hmm... I'm not happy about having two separate material kinds. Perhaps we should make Material opaque for now?

kvark · Jan 2, 2018

kvark requested changes Jan 2, 2018

View changes

kvark · Jan 2, 2018

data/shaders/basic_vs.glsl

 in vec4 i_Color;
 in vec4 i_UvRange;

 void main() {
-    mat4 m_World = mat4(i_World0, i_World1, i_World2, i_World3);
+    mat4 m_World = world_matrix(i_World0, i_World1, i_World2);


can we also move the in vec4 i_World? into the header?

If you think we need it, sure.

kvark · Jan 2, 2018

data/shaders/world_matrix.glsl

@@ -0,0 +1,7 @@
+mat4 world_matrix(vec4 i_World0, vec4 i_World1, vec4 i_World2) {


I don't think it needs a header, tbh, since all you need is
transpose(mat4(i_World0, i_World1, i_World2, vec4(0.0,0.0,0.0,1.0)))

Is transpose cheap operation?

alteous · Jan 2, 2018

alteous reviewed Jan 2, 2018

View changes

alteous · Jan 2, 2018

src/safe_float.rs

+pub struct SafeFloat(f32);
+
+impl SafeFloat {
+	pub fn try_from(value: f32) -> Option<Self> {


vitvakatu · Jan 3, 2018

Updated to gfx 16.3, rebased, ready for merge

kvark · Jan 3, 2018

Thanks! A few more things I spotted.
Really happy that we got rid of those pesky unique IDs :)

Reviewed 6 of 17 files at r1, 4 of 10 files at r3, 7 of 9 files at r4, 7 of 8 files at r5.
Review status: all files reviewed at latest revision, 16 unresolved discussions.

Cargo.toml, line 27 at r5 (raw file):

[dependencies]
bitflags = "0.9"
byteorder = "1.2"

this is not needed

examples/group.rs, line 135 at r5 (raw file):

    let timer = win.input.time();
    println!("{}", cubes.len());

plz make it prettier a bit, describe what the number is for

src/material.rs, line 202 at r5 (raw file):

#[doc(hidden)]
#[derive(Clone, Debug, PartialEq, Eq, Hash)]
pub struct InternalPbr {

this goes against our "convention" (e.g. Node -> NodeInternal). How about PbrInternal?

src/material.rs, line 265 at r5 (raw file):

#[doc(hidden)]
#[derive(Clone, Debug, PartialEq, Eq, Hash)]
pub struct InternalPhong {

same here, let's be consistent

src/safe_float.rs, line 17 at r5 (raw file):

    pub fn new(value: f32) -> Self {
        Self::try_from(value).expect("Illegal float value")

could be From<f32>

src/safe_float.rs, line 28 at r5 (raw file):

        state: &mut H,
    ) {
        self.0.to_bits().hash(state);

wonder if it's going to be simpler to store it as u32 and auto-derive Hash and some others

src/texture.rs, line 26 at r5 (raw file):

impl<T> Hash for Texture<T> {
    fn hash<H: Hasher>(

can this impl be auto-derived?

src/factory/mod.rs, line 263 at r5 (raw file):

                GpuData {
                    slice,
                    vertices: vbuf.clone(),

why is clone() needed here?

src/factory/mod.rs, line 305 at r5 (raw file):

        };
        let instances = self.create_instance_buffer();
        let material = material.into();

can we do this in-place below, like the old code did?

src/factory/mod.rs, line 368 at r5 (raw file):

                instances,
                instance_cache_key: Some(InstanceCacheKey {
                    material: material.clone(),

does it need a clone() here?

src/factory/mod.rs, line 889 at r5 (raw file):

                        GpuData {
                            slice,
                            vertices: vbuf.clone(),

why is clone() needed here?

src/render/mod.rs, line 28 at r5 (raw file):

pub use self::back::Factory as BackendFactory;
pub use self::back::Resources as BackendResources;
use self::pso_data::PsoData;

let's move it out of pub use section

src/render/mod.rs, line 214 at r5 (raw file):

        uv_range: [f32; 4],
        param: f32,
    ) -> Instance {

Self

src/render/mod.rs, line 216 at r5 (raw file):

    ) -> Instance {
        Instance {
            world0: mx_world[0],

hmm, shouldn't it be transposed here?

src/render/mod.rs, line 220 at r5 (raw file):

            world2: mx_world[2],
            color: {
                let rgb = color::to_linear_rgb(color);

we could make this helper more useful by adding a parameter for W and returning [f32; 4] right away. Perfectly fine for a follow-up :)

src/render/mod.rs, line 229 at r5 (raw file):

    #[inline]
    fn pbr(mx_world: [[f32; 4]; 4]) -> Instance {

Self

Comments from Reviewable

vitvakatu · Jan 3, 2018

Review status: all files reviewed at latest revision, 16 unresolved discussions.

Cargo.toml, line 27 at r5 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

this is not needed

Oh, rebasing issue. Nicely spotted!

src/safe_float.rs, line 17 at r5 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

could be From<f32>

No, From must not panic

Comments from Reviewable

vitvakatu · Jan 3, 2018

Review status: all files reviewed at latest revision, 16 unresolved discussions.

Cargo.toml, line 27 at r5 (raw file):

Previously, vitvakatu (Ilya Bogdanov) wrote…

Oh, rebasing issue. Nicely spotted!

Done.

examples/group.rs, line 135 at r5 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

plz make it prettier a bit, describe what the number is for

Done.

src/material.rs, line 202 at r5 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

this goes against our "convention" (e.g. Node -> NodeInternal). How about PbrInternal?

Done.

src/material.rs, line 265 at r5 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

same here, let's be consistent

Done.

src/safe_float.rs, line 28 at r5 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

wonder if it's going to be simpler to store it as u32 and auto-derive Hash and some others

I prefer to leave it for now

src/texture.rs, line 26 at r5 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

can this impl be auto-derived?

No, because of type parameter

src/factory/mod.rs, line 263 at r5 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

why is clone() needed here?

Done.

src/factory/mod.rs, line 305 at r5 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

can we do this in-place below, like the old code did?

Done.

src/factory/mod.rs, line 368 at r5 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

does it need a clone() here?

Yes

src/factory/mod.rs, line 889 at r5 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

why is clone() needed here?

Done.

src/render/mod.rs, line 28 at r5 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

let's move it out of pub use section

Done.

src/render/mod.rs, line 214 at r5 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

Self

Done.

src/render/mod.rs, line 216 at r5 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

hmm, shouldn't it be transposed here?

I assume that it's already transposed, so not

src/render/mod.rs, line 220 at r5 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

we could make this helper more useful by adding a parameter for W and returning [f32; 4] right away. Perfectly fine for a follow-up :)

Will cover in follow-up

src/render/mod.rs, line 229 at r5 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

Self

Done.

Comments from Reviewable

kvark · Jan 3, 2018

Reviewed 5 of 5 files at r6.
Review status: all files reviewed at latest revision, 3 unresolved discussions.

src/texture.rs, line 26 at r5 (raw file):

Previously, vitvakatu (Ilya Bogdanov) wrote…

No, because of type parameter

Will be possible with derivative crate, like how gfx-rs does does this. (for a follow-up, but please leave a TODO comment there)

src/render/mod.rs, line 216 at r5 (raw file):

Previously, vitvakatu (Ilya Bogdanov) wrote…

I assume that it's already transposed, so not

I see. Let's either have it reflected in the parameter name, or even use the strongly typed mint::RowMatrix there

src/render/mod.rs, line 220 at r5 (raw file):

Previously, vitvakatu (Ilya Bogdanov) wrote…

Will cover in follow-up

thanks! please add a TODO comment

Comments from Reviewable

vitvakatu · Jan 3, 2018

Review status: all files reviewed at latest revision, 3 unresolved discussions.

src/texture.rs, line 26 at r5 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

Will be possible with derivative crate, like how gfx-rs does does this. (for a follow-up, but please leave a TODO comment there)

Done.

src/render/mod.rs, line 216 at r5 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

I see. Let's either have it reflected in the parameter name, or even use the strongly typed mint::RowMatrix there

Good advice, found issue in shadow rendering. Done.

src/render/mod.rs, line 220 at r5 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

thanks! please add a TODO comment

Done.

Comments from Reviewable

kvark · Jan 3, 2018

Reviewed 2 of 2 files at r7.
Review status: all files reviewed at latest revision, 1 unresolved discussion.

src/render/mod.rs, line 216 at r5 (raw file):

Previously, vitvakatu (Ilya Bogdanov) wrote…

Good advice, found issue in shadow rendering. Done.

extra nit: no need to reflect it no both the name and the type. Only the type is clear enough, and we can have a shorter name ;)

Comments from Reviewable

kvark · Jan 3, 2018

kvark approved these changes Jan 3, 2018

View changes

vitvakatu · Jan 3, 2018

Review status: all files reviewed at latest revision, 1 unresolved discussion.

src/render/mod.rs, line 216 at r5 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

extra nit: no need to reflect it no both the name and the type. Only the type is clear enough, and we can have a shorter name ;)

Done.

Comments from Reviewable

kvark · Jan 3, 2018

Reviewed 1 of 1 files at r8.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable

kvark · Jan 3, 2018

Reviewed 7 of 7 files at r9.
Review status: all files reviewed at latest revision, 2 unresolved discussions.

src/texture.rs, line 4 at r9 (raw file):

use render::BackendResources;
use std::path::Path;
use util;

I typically order imports into groups: dependencies, this crate, std. Not a big deal though, I assume rustfmt will overwrite this?

src/texture.rs, line 21 at r9 (raw file):

    sampler: h::Sampler<BackendResources>,
    total_size: [u32; 2],
    #[derivative(Hash(hash_with = "util::hash_f32_slice"))] tex0: [f32; 2],

let's split in 2 lines, like everywhere else

Comments from Reviewable

vitvakatu · Jan 3, 2018

Review status: all files reviewed at latest revision, 2 unresolved discussions.

src/texture.rs, line 4 at r9 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

I typically order imports into groups: dependencies, this crate, std. Not a big deal though, I assume rustfmt will overwrite this?

Done.

src/texture.rs, line 21 at r9 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

let's split in 2 lines, like everywhere else

Oh, it's rustfmt. Should I disable formatting for this struct?

Comments from Reviewable

kvark · Jan 3, 2018

🐑 it 💯 🥇
bors r+

alteous · Jan 3, 2018

bors · Jan 3, 2018

Build succeeded

continuous-integration/travis-ci/push

vitvakatu requested review from kvark and alteous Dec 9, 2017

vitvakatu force-pushed the vitvakatu:auto_instancing branch from e580f3c to a4f7ee1 Dec 9, 2017

kvark referenced this pull request Dec 30, 2017
Closed
Consider Three-rs for the engine #21

vitvakatu changed the title ~~[WIP] Auto instancing~~ Auto instancing Jan 2, 2018

Add FPS counter to group example

50c9da8

vitvakatu force-pushed the vitvakatu:auto_instancing branch from 77ce0e7 to d6d0648 Jan 2, 2018

vitvakatu added some commits Nov 9, 2017

Implement auto instancing

726ce7f

Auto instancing refactoring

dfb370e

vitvakatu force-pushed the vitvakatu:auto_instancing branch 3 times, most recently from e341ddc to 941c747 Jan 2, 2018

vitvakatu force-pushed the vitvakatu:auto_instancing branch from 941c747 to 38c1b6d Jan 3, 2018

vitvakatu force-pushed the vitvakatu:auto_instancing branch from 38c1b6d to a2df0d0 Jan 3, 2018

vitvakatu force-pushed the vitvakatu:auto_instancing branch from a2df0d0 to 91d63f4 Jan 3, 2018

vitvakatu added some commits Dec 23, 2017

Implement Hash and Eq for Material

06fa9e3

Pack world matrix in three vectors

4e509e1

vitvakatu force-pushed the vitvakatu:auto_instancing branch from 91d63f4 to 6f2f20c Jan 3, 2018

Rustfmt 0.3.4

Loading status checks…

d0f7539

vitvakatu force-pushed the vitvakatu:auto_instancing branch from 6f2f20c to d0f7539 Jan 3, 2018

bors bot merged commit d0f7539 into three-rs:master Jan 3, 2018
2 checks passed

2 checks passed

bors Build succeeded

continuous-integration/travis-ci/pr The Travis CI build passed
Details

three-rs/three

Join GitHub today

Auto instancing #150

Conversation

vitvakatu commented Dec 9, 2017 • edited

Insanity?

What have you done?

Worth it?

vitvakatu requested review from kvark and alteous Dec 9, 2017

vitvakatu force-pushed the vitvakatu:auto_instancing branch from e580f3c to a4f7ee1 Dec 9, 2017

This comment has been minimized.

alteous commented Dec 9, 2017

This comment has been minimized.

kvark commented Dec 11, 2017

kvark reviewed Dec 11, 2017 View changes

kvark left a comment

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

vitvakatu commented Dec 11, 2017

This comment has been minimized.

vitvakatu commented Dec 15, 2017

kvark reviewed Dec 15, 2017 View changes

kvark left a comment

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

alteous reviewed Dec 19, 2017 View changes

This comment has been minimized.

This comment has been minimized.

alteous Dec 19, 2017 • edited

This comment has been minimized.

alteous reviewed Dec 19, 2017 View changes

This comment has been minimized.

This comment has been minimized.

alteous approved these changes Dec 19, 2017 View changes

alteous left a comment

kvark approved these changes Dec 24, 2017 View changes

kvark left a comment

This comment has been minimized.

vitvakatu commented Dec 25, 2017

kvark referenced this pull request Dec 30, 2017

alteous reviewed Jan 1, 2018 View changes

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

kvark commented Jan 2, 2018

This comment has been minimized.

vitvakatu commented Jan 2, 2018

vitvakatu changed the title [WIP] Auto instancing Auto instancing Jan 2, 2018

kvark requested changes Jan 2, 2018 View changes

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

alteous reviewed Jan 2, 2018 View changes

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

kvark requested changes Jan 2, 2018 View changes

This comment has been minimized.

This comment has been minimized.

vitvakatu commented Dec 9, 2017 •

edited

vitvakatu force-pushed the vitvakatu:auto_instancing branch from `e580f3c` to `a4f7ee1` Dec 9, 2017

kvark reviewed Dec 11, 2017

View changes

kvark reviewed Dec 15, 2017

View changes

alteous reviewed Dec 19, 2017

View changes

alteous Dec 19, 2017 •

edited

alteous reviewed Dec 19, 2017

View changes

alteous approved these changes Dec 19, 2017

View changes

kvark approved these changes Dec 24, 2017

View changes

alteous reviewed Jan 1, 2018

View changes

kvark requested changes Jan 2, 2018

View changes

alteous reviewed Jan 2, 2018

View changes

kvark requested changes Jan 2, 2018

View changes

alteous reviewed Jan 2, 2018

View changes

vitvakatu force-pushed the vitvakatu:auto_instancing branch from `77ce0e7` to `d6d0648` Jan 2, 2018

vitvakatu force-pushed the vitvakatu:auto_instancing branch 3 times, most recently from `e341ddc` to `941c747` Jan 2, 2018

vitvakatu force-pushed the vitvakatu:auto_instancing branch from `941c747` to `38c1b6d` Jan 3, 2018

vitvakatu force-pushed the vitvakatu:auto_instancing branch from `38c1b6d` to `a2df0d0` Jan 3, 2018