Jump to content

  • Log In with Google      Sign In   
  • Create Account


Platform-agnostic renderer


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
51 replies to this topic

#41 ATC   Members   -  Reputation: 551

Like
0Likes
Like

Posted 12 September 2012 - 02:07 PM

How do you propose I set things up so that my renderer knows what technique and/or passes it is supposed to be using, and do so in a way that it will be suitable to inherit and re-implement for OpenGL. I'm still struggling with a clean way to implement this...
_______________________________________________________________________________
CEO & Lead Developer at ATCWARE™
"Project X-1"; a 100% managed, platform-agnostic game & simulation engine


Please visit our new forums and help us test them and break the ice!
___________________________________________________________________________________

Sponsor:

#42 swiftcoder   Senior Moderators   -  Reputation: 9672

Like
0Likes
Like

Posted 12 September 2012 - 02:36 PM

How do you propose I set things up so that my renderer knows what technique and/or passes it is supposed to be using, and do so in a way that it will be suitable to inherit and re-implement for OpenGL. I'm still struggling with a clean way to implement this...

My opinion is that functionality doesn't belong in the renderer at all - all the renderer knows about are individual shaders.

You then write some sort of processor outside the renderer, which takes an API-agnostic 'effect file', and picks which shaders to send down to the renderer. That way the processor can pick from GLSL or HLSL files as necessary, and how you structure and use multi-pass effects is entirely up to you.

Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]


#43 ATC   Members   -  Reputation: 551

Like
0Likes
Like

Posted 12 September 2012 - 03:28 PM

Does the attached file more or less tell the tale with the right idea?

Basically, I'm thinking that the Renderer would hold a reference to the shader being actively used... Global FX variables can be set on that shader as needed. A RenderOp contains its own "local" variable sets it can apply to the shader to draw the current mesh. The material is basically, well... a material, which is like a specialized parameter set for an existing shader. Or perhaps the material and this "local variable" set should be one and the same?

Anyways, everything else would work as expected... the RenderOp's mesh data is where we get our index and vertex buffers... and I'm thinking that I can use the (string[]) Commands field for selecting what techniques/passes are in use! I could eventually turn out a miniature scripting interface for applying more advanced shading techniques with numerous passes, blending and render states...

All of this seem about right?

Attached Thumbnails

  • RenderingSystem.jpg

_______________________________________________________________________________
CEO & Lead Developer at ATCWARE™
"Project X-1"; a 100% managed, platform-agnostic game & simulation engine


Please visit our new forums and help us test them and break the ice!
___________________________________________________________________________________

#44 TheBlackDeath   Members   -  Reputation: 87

Like
-1Likes
Like

Posted 12 September 2012 - 10:49 PM

I love all the elitists bashing Ogre3D. It's amusing.

#45 ATC   Members   -  Reputation: 551

Like
0Likes
Like

Posted 12 September 2012 - 11:11 PM

I love all the elitists bashing Ogre3D. It's amusing.


Your opinion means just as much as my opinion and everyone else's (not much, lol). But let's please not hijack the thread to argue about OGRE or other engines! I'm trying to perfect a design with community input, and doing so will sorta ruin my thread, ya digg? ;-)
_______________________________________________________________________________
CEO & Lead Developer at ATCWARE™
"Project X-1"; a 100% managed, platform-agnostic game & simulation engine


Please visit our new forums and help us test them and break the ice!
___________________________________________________________________________________

#46 swiftcoder   Senior Moderators   -  Reputation: 9672

Like
0Likes
Like

Posted 13 September 2012 - 06:27 AM

I love all the elitists bashing Ogre3D. It's amusing.

We aren't bashing Ogre - it's a great engine. It's also one of the worst examples of software engineering I can think of. C'est la vie.

Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]


#47 ATC   Members   -  Reputation: 551

Like
0Likes
Like

Posted 13 September 2012 - 09:11 AM

We aren't bashing Ogre - it's a great engine. It's also one of the worst examples of software engineering I can think of. C'est la vie.


Well put. Court is adjourned. :-)

You have been very gracious and helpful to me, as have others. Did you see my post with the diagram, and does that seem to make sense and convey the right idea?
_______________________________________________________________________________
CEO & Lead Developer at ATCWARE™
"Project X-1"; a 100% managed, platform-agnostic game & simulation engine


Please visit our new forums and help us test them and break the ice!
___________________________________________________________________________________

#48 phantom   Moderators   -  Reputation: 6805

Like
1Likes
Like

Posted 13 September 2012 - 03:15 PM

Did you see my post with the diagram, and does that seem to make sense and convey the right idea?


It's close but the key thing I would say is that a 'material' is a combination of shader and it's resources.

Nor should it have to worry about 'external FX variables'; anything which isn't set by the material or the draw call directly (per-instance/batch stuff) should be handled by some external system. So things like camera position and the like, which are setup once per scene, would be set via something else and just read.

In the context of DX11 this would be a per-scene constant block, the material would be a per-material constant block and the instance data would be one or more per-instance blocks.

Keep your frequency of updates down as much as you can for each block, try to instance things too as CPU time is still a killer if you want to handle lots of draw calls.

#49 TheBlackDeath   Members   -  Reputation: 87

Like
-3Likes
Like

Posted 13 September 2012 - 05:40 PM


We aren't bashing Ogre - it's a great engine. It's also one of the worst examples of software engineering I can think of. C'est la vie.


Well put. Court is adjourned. :-)

You have been very gracious and helpful to me, as have others. Did you see my post with the diagram, and does that seem to make sense and convey the right idea?

Like you said, because you say court is adjourned does not mean court is adjourned, tool.

#50 ATC   Members   -  Reputation: 551

Like
0Likes
Like

Posted 13 September 2012 - 10:43 PM

Like you said, because you say court is adjourned does not mean court is adjourned, tool.


I wasn't nasty or rude to you in any way, so I definitely don't appreciate that. I think something is wrong when two men can't get along because they favor different game engines (And I'm actually neutral on OGRE; neither for or against). Please, let's let this go no further here. If you want to curse me out, call me names, etc just send it in a pm and please let me discuss my design questions in this thread. If you'd like to join that discussion you are welcome with open arms.

One thing we can all agree on is that when it comes to game engines, Ogre is a game engine. :-)
_______________________________________________________________________________
CEO & Lead Developer at ATCWARE™
"Project X-1"; a 100% managed, platform-agnostic game & simulation engine


Please visit our new forums and help us test them and break the ice!
___________________________________________________________________________________

#51 ATC   Members   -  Reputation: 551

Like
0Likes
Like

Posted 13 September 2012 - 10:49 PM

It's close but the key thing I would say is that a 'material' is a combination of shader and it's resources.

Nor should it have to worry about 'external FX variables'; anything which isn't set by the material or the draw call directly (per-instance/batch stuff) should be handled by some external system. So things like camera position and the like, which are setup once per scene, would be set via something else and just read.

In the context of DX11 this would be a per-scene constant block, the material would be a per-material constant block and the instance data would be one or more per-instance blocks.

Keep your frequency of updates down as much as you can for each block, try to instance things too as CPU time is still a killer if you want to handle lots of draw calls.


Thank you... So my initial design of having the Material class hold a reference to a Shader was actually not incorrect/badly-designed?

I didn't say the Material class would worry about "external" variables... I only meant that variables can be set on the shader from without the Material (e.g., an update call to set a World or WVP matrix)... that's what I mean by them being "global", as a model, for instance, will typically apply the same world transformation to all its mesh-parts (excepting some animation cases; in which case certain bone/parent transformations will be "global" to child nodes). Sound more reasonable?
_______________________________________________________________________________
CEO & Lead Developer at ATCWARE™
"Project X-1"; a 100% managed, platform-agnostic game & simulation engine


Please visit our new forums and help us test them and break the ice!
___________________________________________________________________________________

#52 ATC   Members   -  Reputation: 551

Like
0Likes
Like

Posted 18 September 2012 - 01:57 AM

Hey guys, maybe you can help me get back on the right track? I'm still struggling with ideas on how best to implement the shading and material system, and how the renderer should handle it. Like I said earlier, I came up with the idea of allowing users to supply a simple type of script alongside a Material, to control how it uses the underlying shader. Here's an example of this proposed script and how it might look:

[source lang="csharp"]technique = 1{ passes { p0, p1, p2, };};[/source]

The parser for such scripts could be quite simple... perhaps even this simple:

[source lang="csharp"]public class Test { static readonly string[] _keywords = new[] { "technique", "passes", "commands" }; internal static Technique _ProcessScript(string script) { //! Ensure script is valid! if (string.IsNullOrEmpty(script)) throw new NullReferenceException("Invalid/null material script!"); //! Select defaults if blank... if (script.Length < 1) return new Technique("0", new Pass("ALL")); var next = ""; List<string> tokens = new List<string>(); foreach (char c in script) { switch © { case ' ': case '\n': case '\r': case ' ': case '{': case '}': case ';': case '"': case '=': case ',': if (!string.IsNullOrEmpty(next) && !(next == "technique") && !(next == "passes")) tokens.Add(next); next = ""; break; default: if(!char.IsLetterOrDigit©) throw new Exception(string.Format( "Invalid token '{0}' in script!", c.ToString())); next += c; break; } } Technique technique = new Technique(tokens[0]); for (int i = 1; i < tokens.Count; ++i) technique.Passes.Add(new Pass(tokens[i])); return technique; } }[/source]

And here are example supporting classes for "Technique" and "Pass", which really only serve for identification's sake...

[source lang="csharp"] public class Pass { public Pass(string name) { this.Name = name; } public string Name { get; set; } } public class Technique { public Technique(string name) { this.Name = name; this.Passes = new List<Pass>(); } public Technique(string name, params Pass[] passes) { if (passes == null) throw new ArgumentNullException("techniques"); this.Name = name; this.Passes = new List<Pass>(passes); } public Technique(string name, List<Pass> passes) { if (passes == null) throw new ArgumentNullException("passes"); this.Name = name; this.Passes = passes; } public string Name { get; set; } public List<Pass> Passes { get; set; } }[/source]

Does pursuing this concept further seem like a bad idea? Why or why not? What do you think is the best way to implement such a thing, or should this whole material script idea be trashed and a better method used (if so, what is that better method?)?

Maybe most importantly, I'm wondering how the Renderer should, in theory, break down all this data to process and render it. This is the first time I've written any platform-agnostic game or engine code, and my first true data-driven Renderer implementation. So much of this is new to me and I'm trying to grasp the concepts/design; writing the code is the easy part! ;-)

------------------------------------------------------------------------
EDIT:
------------------------------------------------------------------------
To whom it may concern, there is a bug with the forum code blocks... With C# selected it does not seem compatible with the '<' and '>' characters used for generics. For instance, "List<Pass> passes" comes out as "List passes".

Edited by ATC, 18 September 2012 - 02:00 AM.

_______________________________________________________________________________
CEO & Lead Developer at ATCWARE™
"Project X-1"; a 100% managed, platform-agnostic game & simulation engine


Please visit our new forums and help us test them and break the ice!
___________________________________________________________________________________




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS