Once a simple Inter-process communication was established between the PDE and Shdr, the next step was to implement Shader recompilation in Processing. For this Shdr needs to tell the PDE to recompile it's shader program, whenever it's own default shader is compiled successfully. This would be established using IPC. 

However, an interesting question came up here. What would be the point of sending the GLSL code from the Shdr tool to the PDE when the user can already see the rendered output in Shdr's default rendering window?

The main reason for sending data from the Shdr tool to the PDE was so that PDE could compile that glsl code using it's own rendering machine. But since Shdr already has a rendering window of it's own that updates in realtime, a separate PDE display window is not needed. The catch here though was that the Shdr tool only shows the shader applied on a simple 3D object. However the processing sketch maybe using the shader in combination with other elements due to which the PDE's output window may look different. This is demonstrated in the two examples below. 

After discussing with my mentor we decided that before proceeding, it would be useful to compare how the shader looks like on a simple geometry vs in a more complex scene, both in the Shdr tool and PDE's shader output. Here are two examples shared by my mentor (Andres Colubri),

Case 1 - Simple geometry in Processing

Case 1 - the same shader code implemented in Shdr (GLSL editor)

Case 2 - Complex geometry in Processing

It was found that Shdr generated the same output for Case 2 as it did for Case 1. Thus in the end it was decided to keep both displays, for debugging purposes for the user. 

My next step was to refine the IPC system I had developed earlier. Uptil now communication between the PDE and Shdr comprised one cycle only in which the Server would listen for client messages and would disconnect after receiving and printing a message from client (Shdr-electron). In order for the PDE to recompile the shader multiple times a continuous communication needed to be established. To achieve that I had to make the PDE (server) send back a message to Shdr when it received a message from Shdr. Shdr in turn always listened for PDE's response before emitting another message. In this way a continuous stream of messages was passed between the PDE and Shdr.

 

The new changes I made to the IPC code in Shdr was adding a client.on function that listened for server messages and an output buffer in the server file for the PDE in eclipse, along with some print and flush statements that printed received messages to the console. I also had to move the serverSocket.accept() function call before the while loop as otherwise server would look for a new connection every time. Once a connection has been accepted from client, server doesn’t need to look for a new connection anymore.

Shdr-electron code:

Eclipse PDE tool code:

Demo:

In my attempts to make changes to the app for testing purposes I also realized another mistake that I had made in the beginning. I had been giving electron the URL of the Shdr website instead of the path to the html file in my local directory, due to which any changes made in the local app were not updated. 

New path given:

Summary:

GLSL Editor Weekly Report 4

06/10/2018
This site was designed with the
.com
website builder. Create your website today.
Start Now