Wireframe, revisited

Shaders
1

Hi @John ,

It took me quite a bit to come back to this, but you may recall first whipping up the wireframe shader, and then passing off to me the code I needed to use in Codea to replicate the (original) preview environment for models that is used in Shade (I noticed it is different in Shade now - no skybox).

So today (finally) I was opening the project in Codea and switching the material to Wireframe, but, alas, it doesn’t look correct (See attached).

I also attached a screenshot of the same Wireframe shader (same .shader folder) in Shade, where it looks good (attached).

Finally, to be complete, I attached the Material Preview code to use in Codea.

Any idea what could be happening here?

Thanks!

2

@brianolive - curious, loaded your code into Codea and ran, gave a fully textured sphere. Any reason why you have two of the following lines in your environmentprobe:render() function?


self:renderPlane(1, vec3(1,0,0), vec3(0,1,0))

Tried to load Shade after this - to build your shader up locally and found Shade loaded, but before loading up the opening screen bombed straight out to iPad app screen. Very quickly - anyone else experience this? Any problems recently @John?

Edit: further info - Shade seems to drop back to the iPad app list but, if you drag up on the app screen to get the mini project windows Shade is there but tapping on it opens and immediately closes again. Dragging the mini window off screen closes Shade. I can’t think of anything I have done which could have caused this. Does Shade share any code with Codea - could updating Codea have introduced a bug?

3

Hi @Bri_G , thanks for taking a look. Tbh, the code is @John ‘s. Perhaps the repeated line is an oversight.

I should point out that in addition to the code as is in the zip, I added a camera with this line at the end of Setup:

preview.camera:add(OrbitViewer, vec3(0,1,0), 5, 5, 20)
4

@brianolive I think this is because the wireframe shader requires the vertices of the model to be “split” to function correctly

Notice the line e.model:split() to unique the vertices for each triangle

Try doing this:

-- Sphere

function setup()
    -- Create a new craft scene
    scene = craft.scene()

    -- Create a new entity
    local e = scene:entity()   
    
    e.model = craft.model.icosphere(5.0)
    
    -- We need to split the model
    e.model:split()
    
    -- To make its vertices disconnected so
    --  the wire shader can work
    e.material = craft.material("Project:Wireframe")    
    
    viewer = scene.camera:add(OrbitViewer, e.model.bounds.center, 30, 20, 100)
    
    -- These are parameters on my wireframe shader, yours might not have them!
    parameter.number("Smoothness", 0.0, 8.0, 0.6, function(value)
        e.material.smoothness = value
    end)
    
    parameter.number("Thickness", 0.0, 10.0, 3.0, function(value)
        e.material.thickness = value
    end)
    
    -- Also my cube map, you might want to comment this out
    local sunny = readText("Project:Night")
    local env = craft.cubeTexture(json.decode(sunny))
            scene.sky.material.envMap = env                        

end

function update(dt)
    -- Update the scene (physics, transforms etc)
    scene:update(dt)
end

-- Called automatically by codea 
function draw()
    update(DeltaTime)

    -- Draw the scene
    scene:draw()	
end
5

Yeah adding the model:split() call to the attached Codea project results in the correct appearance. This is only really needed for the wireframe shader due to it requiring unique vertices to compute distance from the triangle edges.

6

@Simeon - post above with Shade bombing immediately is due to expiry of beta version. Haven’t used it for a while and beta expired. Re-installed and now OK.

7

Thanks @Simeon I remember @John creating that split method to support the wireframe code in the first place. I had forgotten about it since. Thanks!

8

Not a big deal, but I noticed that when I take a picture of wireframed entities using the Codea camera, then the space between the ‘wires’ becomes a white color. Take a screenshot (iOS-style) and it appears correct. Doesn’t matter to me, but thought perhaps that @Simeon or @John might see it as a symptom of something more significant that they would want to fix. (see attached images)

9

@brianolive interesting find, thank you for reporting it

Might be due to the way we set up the off-screen render path for the screenshot