Team Happy coding!

[manu3d]

• Name: "Emanuele 'manu3d' D'Arrigo"
• Social: github: emanuele3d.
• From: Originally Italian, from Pisa, based in Basel, Switzerland for the last 3.5 years, after 4 years in Munich, Germany and 8 years near London, England.
• Skills / Tools: 3D/VFX: primarily Maya, and long time ago Softimage. After some general work on TV ads I started working in "special ops" teams and eventually effects teams (fire, rain, dust, magical effects...). My credit list is here. Programming: in chronological order since 1995, csh, tcl, C/C++, mel, php, python and over the past couple of years, java. Mostly for smallish, glue-like or problem-solving tools, i.e. handling crowds. Sometimes for larger projects, but nothing the size of Terasology.
• Found via: Google, searching for Minecraft-like games, minecraft clones.
• Interests: 3D procedural generation, game design, simulation, educational applications of game tech for both children and adults.
• Extra: Full-time dad, of a 3 years old and a 2 months old. Used to play basketball until one of the knees decided it had enough. Other interests are Science, Technology, Economics and Politics.

 

[Cervator]

Nice to see an intro post from you - welcome again!

Impressive credits - very cool. Didn't realize you had that much XP in GFX. Does that extend into 3D wizardry in OpenGL / LWJGL, curiously? We could use some more shader wizards

We've had a few people with some neat educational ideas for the game. One of the topics I'd love to explore more one day.

 

[manu3d]

Indeed I have a fair amount of experience in the field of 3D visual effects. Or at least I had. Now I'm certainly quite rusty. It has been years. And my rendering times measured in cpu/hours, per frame, -per layer-. Real-time computational budgets, even if aided by the GPU's parallelism, are rather different.

The only thing I did with (pure) opengl was a C/C++ based cubic tic-tac-toe and it was probably around the year 2001. So, not much luck there. Shader-wise, in the industry I used them but I never had to write them. I was on the modelling/animation/simulation side of the pipeline. Shading/lighting/compositing was the other side and I had plenty to know and learn about on my side, so I never really ventured beyond it. Because of Terasology I had my first proper look at how shaders work on the LWJGL website. I'll certainly have to deal with them for necessity in the context of the Sky System, but it's not one of my primary interests. Sorry.

Can you dig out those educational ideas? If not, do you remember some keywords I could use to find them? I presume they discussed them here in the forum?

 

[Cervator]

Hmm, I know woodspeople had a lot of interesting ideas in that field back when she was around (been a while now though) and there's this thread - but other than that I can't find anything in the forum right now. May in part have been IRC discussion which then of course rarely gets persisted somewhere else, sigh Long time ago since last in any case.

Understandable on the 3D wizardry point, still cool!

 

[Marcin Sciesinski]

Wow, impressive credits! Welcome!

 

[manu3d]

Thank you Cervator for the link and thank you both for the welcome!

 

[manu3d]

Update:

• running from source (via IntelliJ)
• getting acquainted with codebase (ES via existing modules and rendering system in particular)
• getting acquainted with cooperative/git-based workflow and tools

 

[manu3d]

Update:

• accumulated a number of small edits and code-specific questions while learning parts of the engine's code.
• now I "just" have to figure out what's the correct git workflow to eventually issue a (gasp!) pull request.
• EDIT: managed to issue the pull request. That part of the process on github is a little clearer.

I'm a bit confused though. For small edits as I go along learning the codebase, should I -not- directly edit my fork of develop? Should I open a "learning" branch?

 

[Cervator]

I think it depends on a few elements:

• Very small and obvious bug fixes and clear documentation additions can easily go in a develop branch and be PRed back
• Anything specialized that might need to be judged on its own aside from anything else should have its own "topic" branch - otherwise you might get half a perfect request stuck because of the other half
• Anything uncertain, controversial or with questions should be in a branch that might not be merged at all, but is more for reference. Then discussion can happen in the forum, on IRC, or in a PR. The final code piece could be done in a fresh new branch when ready
• Anything that's just an experiment or a draft should get its own branch

Really, pretty much anything could just as well get its own branch. Git makes branches very cheap

What you can do is work in your develop branch, then before committing consider what scenario you're in. If you think it would be good to isolate the changes simply make a branch and then commit - your pending changes will move to the new branch effortlessly, then after the commit you can hop back to develop if you need to do something else or continue

 

[manu3d]

Hmmm...

Well, first of all thanks for providing some guidelines. By the sound of it, I messed up. In the sense that my very first PR, which I issued only a few days ago, is a perfect mix of scenario 1 (small changes, documentation) and scenario 3 (with questions). Immortius saw right through it though and closed it without merging it in, although he was kind enough to answer to each issue.

Ok, I need to understand a bit better how my workflow should be in this situation. What I did to get to the PR mentioned above is to go through files, add comments, change small things and add some questions. At the end I therefore found myself with an heterogeneous number of changes that really needed to be on two branches: one for added comments and small changes and the other for questions. So, my question is: should I, from this scenario, proceed to manually split the changes onto two branches, or should I have not even arrived at this scenario, i.e. by disciplining myself to only focus on asking questions in one branch and do changes in another?

Also, how big should a PR be? Is it common to have one PR per file or even per change?

Thanks again for your help!

 

[Cervator]

I'd suggest two fresh branches, one for "accepted" tweaks and one for further discussion

I also put some comments on the PR itself

PR size is more about scope than lines/files changed. If you completely rework an inventory system the PR will be "huge" but scoped to "one" change in a way

If a few smaller changes are highly related they could also naturally fit in one PR together, especially if they build upon each other

 

[manu3d]

Just a quick note to excuse my silence in the past week or so. Here at home we have all been sick with some kind of virus, which is never fun if you are both sick AND have to take care of young children. I will be hopefully up and coding again in a matter of days, perhaps by the end of the week.

 

[Cervator]

Eep! Sorry to hear. No excuse needed, RL comes first. Hope you all get well soon

 

[manu3d]

Update:

• in the process of wrapping up work on PCFacade//Terasology.java, engine//TerasologyEngine.java and engine//StateMainMenu.java
• getting my OpenGL knowledge back on track (no biggie, just 10 years of catching up to do...)

 

[manu3d]

Update:

• Read: OpenGL SuperBible: Comprehensive Tutorial and Reference (6th Edition) - ok-ish, some particularly effective examples
• Read: OpenGL Programming Guide (8th Edition) - vastly superior, should have read it first
• Had matrix-esque moment: "I know OpenGL"
• Then checked my surroundings worried of finding Immorpheus leaning over me saying: "Show me".
• Bought Physically Based Rendering (2nd Edition), to find out where the cutting edge is...
• Tempted by the GPU Pro series, haven't made a move yet.

 

[manu3d]

Update:

• Getting deeper and deeper into the labyrinthine meanders of the rendering code - currently refactoring WorldRendererLwjgl but soon starting to look into shaders in use and the bowels of the rendering system: the DefaultRenderingProcess class.
• Currently reading "Physically Based Rendering (2nd Edition)". Probably not too useful for realtime graphics, but it covers a lot of interesting advanced stuff.

 

[Esereja]

if you ever have time, and if it is easy. can you create option to run 3d mode on normal screen so that we have splitted screen other side having left eye and other right (Cross eye 3d). I have been wanting to do that for year for now but my skills don't allow me to do it atm. If it is lot of work ignore this request, I don't want to burden you.
That just allows 3d wiew for everyone without any extra equipment.

 

[manu3d]

Apologies for not replying promptly: my wife was away on a business trip for a few nights and my days alone with the children started at 04:00 and ended a 23:00 - not much time to breathe and I'm still recovering!!!

@Esereja: theoretically it shouldn't be too difficult and it should be somewhere in the code I'm currently looking at or very nearby. I am a bit concerned by the stereo code being tightly tied with Oculus rather than with a more generic Stereo setup. So, don't hold your breath, but I'll see what I can do.

Incidentally, I found the book "OpenGL Game Programming" on my dusty computer graphics bookshelf. The book is about OpenGL 1.2 so I'm using to "catch-down" with the OpenGL commands used in Terasology's rendering code from the OpenGL 4.3 that I've recently learned about.

 

[manu3d]

• finished reading OpenGL Game Programming (about OpenGL 1.2)
• studying the LwjglRenderingProcess class, the opengl core of the renderer - finding lots of opportunities for refactoring and massive opportunities for adding documentation. =)

 

[manu3d]

Update: latest batch of renderfactoring coming along nicely. All existing functionality is back in place and working as intended after some incidental bugfixing. I should be two commits away from a PR, one to add javadocs and comments, the other for a final polishing round. ETA: end of the coming week.