Contributor Hello everyone!

[tdgunes]

• Name: Taha Doğan Güneş
• Social: tdgunes
  • Github: github.com/tdgunes
  • Twitter: twitter.com/tdgunes
  • Blog: tdgunes.org
• From: Eskisehir, Turkey, currently computer science student in Ozyegin University, Istanbul, Turkey.
• Skills / Tools:
  • Programming languages: Java, C++/C, Objective-C, Swift, Python
  • Familiar with OpenGL, Blender (wrote an extension for exporting worlds), Django, Qt
  • Intellij, Clion, PyCharm, Xcode
• Found via: GSOC
• Interests: I am interested in issues that are tagged as 3D-Wizardy. Especially New rendering approach for very far distances got my attention. I have previously worked on a primitive open source game engine project called Spy-E. We started from scratch with C++, OpenGL and OpenAL.
• Extra: Currently reading: Real-time Rendering and following Handmade-Quake series
  
  It would be great to meet the mentors of this issue who are begla, KaiKratz, Immortius and manu3d, also great to know their recommendations for making myself prepared for this particular issue.

 

[Skaldarnar]

Hey @tdgunes and welcome to our forums

Your background and experience sounds very interesting! For the 3D wizardry, you should definitely get in touch with @manu3d, he's currently most actively working on our rendering code. If you have not set up the project yet you should start with that (link).

Looking forward to your contributions

 

[Cervator]

Hi @tdgunes and welcome! Yes we badly need more rendering wizards! @manu3d is definitely your best contact at present, he's active here in the forum and sometime on IRC/Slack.

@begla and @Kai Kratz are from the very earliest days and haven't been seen for a long time, but I'll try reaching out to them both now that we got into GSOC. @Immortius is our chief architect but has switched his focus mostly to our Gestalt library which is extracting all the good frameworks from the engine so it can be used in other games as well

 

[manu3d]

Hi @tdgunes! Welcome aboard!

Indeed I have been busy with the rendering code, but mostly to refactor it and make it more accessible for other people. I still have to document a couple of very important top-level classes, most notably WorldRendererImpl, but at least it has been refactored and WorldRendererImpl.render() now reads like an index of pretty much everything that happens every frame. So, if you want to start to understand what the rendering engine does, that's your entry point.

Regarding far away rendering, I haven't given it much thought as there is so much to do for the rendering engine to become more flexible and scalable before I can even think of adding new features. So, you pretty much have a blank slate on that. That been said, feel free to bounce ideas on me. I'll do what I can within the constraints of my day (and night) job: full time dad.

Again, welcome aboard.

 

[tdgunes]

Hello everyone,

Thanks for the warm welcome and the badge . @manu3d, I was a little busy last week, I will be checking out WorldRendererImpl this week. It seems like before getting into the issue that I mentioned, there seems to be a significant amount of refactor needed in the rendering engine, as you mentioned. I will try to get back to you with my findings as soon as I can.

By the way, what would be the best way to contact to you directly @manu3d?

Thanks again.

 

[manu3d]

For the time being I'd recommend using this forum: any discussion related to the rendering engine should be public, for the benefit of anybody interested in the subject. Just make sure to tag me so I'll get notified. Alternatively, if you want to discuss specific code, I'd recommend to submit PRs, not necessarily intended for merging. This way we can use github's code-related discussion tools. Again, tagging me will make sure I get extra-notified even though I normally check forum and github on a daily basis.

I look forward to your contributions!

 

[tdgunes]

@manu3d: I thought it would be maybe much faster to do our discussion via IRC or Slack. No problem! .

For contributions, I am trying to get familiar with the organisation of rendering engine. Up till now, I think it's straightforward and fairly nicely done in scope of clean coding. With help of that, I partially fixed an issue. While checking other issues that are about rendering engine, I found "DAG-based Rendering Pipelines" issue, which I think it can be a great GSOC project.

Ultimately, my questions are:

1. Are you going to be a mentor for GSOC? (You are not listed here ).

2. Do you think that "DAG-based Rendering Pipelines" is a good project for GSOC?

Thanks again

 

[manu3d]

Regarding discussions: we can certainly meet on Slack if you like. But I'm on it only late at night (Central European Time) and some nights not at all. So, we might need to plan for it.

Regarding your questions:

1. I'd love to but I can't. I just don't have the kind of time that is required to be a mentor. Also, by the speed at which you are moving through the code, I suspect you'd soon scrape the bottom of my knowledge. I have quite a bit of professional-grade experience in pre-rendered computer graphics, but I joined Terasology to learn about realtime CG and the programming involved. It's not a coincidence my avatar is an apprentice rather than a wizard. That been said, I would certainly support you as much as I can.

2. Yes. It'd be a significant contribution to Terasology and it would make its rendering engine much more flexible and extensible. To give you an idea of where I draw inspiration from, have a look at this Shake tutorial. Whether Terasology might want to have a graph-based interface like Shake is still a matter of debate, but the tutorial visually shows that the final image is the result of processing a number of nodes organized in a DAG. The rendering engine conceptually is not that different: it's all about earlier operations (i.e. renderings) feeding GPU buffers that are then used by later operations (i.e. post-processes). One question mark I have on this regard is "what is the competition doing"? I seem to remember msteiger rightly suggested to check on how other rendering engines make their rendering pipeline extensible. That's something I haven't had the time to research yet. Maybe there are other non-DAG-based approaches that would be just as effective if not easier and faster to implement. But I do think the DAG-based approach would be quite a cool project to work on.