Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Work in Progress / [STICKY] DX11 Plugin

Author
Message
Chris Tate
DBPro Master
15
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 24th Aug 2014 01:37 Edited at: 24th Aug 2014 01:46
Link
No problem; the more often we all play around with it, the more it should help find the errors sooner.

PS: It seams DX11 Set PixelMap Pixel does not correctly accept 4 parameters.

Back to top
Profile PM Email Website
Rudolpho
18
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 24th Aug 2014 12:00
Link
Quote: "PS: It seams DX11 Set PixelMap Pixel does not correctly accept 4 parameters."

Hm, that's odd, it definately should.
This works for me and yields the correct result:


Do you have any snippet of where this fails to work for you?


"Why do programmers get Halloween and Christmas mixed up?"
Back to top
Profile PM Email Website
Chris Tate
DBPro Master
15
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 24th Aug 2014 21:52 Edited at: 24th Aug 2014 21:53
Link
I salute from Sasuke18 on my first snippet page. I told him where to find you.

Quote: "Hello, I'm new here! I was searching the internet for Direct X 11 plugins & came across this plugin & I must say... It looks AMAZING! Keep up the GREAT work!

Sasuke"


Please forgive me, that set pixel parameter issue was a mistake on my part for referencing an invalid array. It works now; I am happy to post this new snippet; but please do explain if I must create a light sources using shaders; at present the coloured spheres feature no highlights or shades; must I create shaders for all my snippets to feature lighting?



Back to top
Profile PM Email Website
Rudolpho
18
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 24th Aug 2014 22:22
Link
Ah, I see.
And thanks for the salutation

Quote: "please do explain if I must create a light sources using shaders; at present the coloured spheres feature no highlights or shades; must I create shaders for all my snippets to feature lighting?"

Yes, I believe this was mentioned either in the help or in a previous post in this thread. DX11 is completely shader based, meaning it needs shaders to render anything at all (this should hold true for DX9 as well). The default shaders I wrote and included with the plugin are very simplistic and does not feature any lighting calculations. Also because everyone may want his lighting to be different (for example how many lightsources as a tradeof of execution speed and memory consumption) and thus end up writing their own shaders to handle lighting anyway I thought there was little reason to provide some built-in functionality like what standard DBPro does with vertex lighting. As you are doubtlessly aware that is implemented in its default shaders and goes away when you set your own too. I might consider writing some lighting shaders to include with the plugin later on, but that would be more like a finishing touch rather than something that is likely to be a priority any time soon.


Also I must say I'm surprised to the relatively low framerate of your example, especially since if I modify it to just group all sphere together in a smaller volume so that they are all visible at once it runs about eight times faster on my machine. I'm guessing there must be something off with the movement functionality that causes these slowdowns. Have you perchance noticed any identifiable source to this while writing your snippet from scratch?


"Why do programmers get Halloween and Christmas mixed up?"
Back to top
Profile PM Email Website
Chris Tate
DBPro Master
15
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 25th Aug 2014 00:20
Link
I do not know why the FPS is so low; it should be about 250-500 FPS by my judgement. With no objects the FPS is 1000. Even in DirectX 10 mode, the same. My Specs:

AMD A4-5300 3.40 GHz (x2 Cores)
8 GB Ram
Windows 8.1 64bit
NVidia Geforce GT 740 - 2 GB DDR 5.

I get more FPS on Counter Strike Global Offensive and Civillization 5. Something is going on; let me know how best to investigate.

About the lighting, I think I will focus on making a simple shader for the remainder of snippets so that the 3D can look more enhanced without too much complexity for learners.

Back to top
Profile PM Email Website
Rudolpho
18
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 25th Aug 2014 01:14 Edited at: 25th Aug 2014 01:19
Link
I found the problem, you're calling DX11 DRAW TEXT in your loop that updates the spheres. Move it outside of the loop and your framerate should go up significantly

Quote: "About the lighting, I think I will focus on making a simple shader for the remainder of snippets so that the 3D can look more enhanced without too much complexity for learners."

That sounds like a nice idea.
If you don't incorporate shadows it shouldn't increase the complexity of your DBPro code anymore than that you would have to set up your own shader technique and assign to your objects.
Once version 0.4 is released you'll also be able to use a new type of structured buffer for providing information to shaders that would lend itself well for representing an array of light sources and data about them. That would make it much easier to change the number of lights on the fly than having to store all the light data in separate fields in a constant buffer.

As for the current plugin development progress, I'm working on a compute shader example project, uncovering bugs and missing features along the way.


"Why do programmers get Halloween and Christmas mixed up?"
Back to top
Profile PM Email Website
Chris Tate
DBPro Master
15
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 25th Aug 2014 22:14
Link
Quote: "you're calling DX11 DRAW TEXT in your loop that updates the spheres"


LOL, how hilarious. Thanks.

Back to top
Profile PM Email Website
GreenDixy
15
Years of Service
User Offline
Joined: 24th Jul 2008
Location: Toronto
Posted: 27th Aug 2014 05:09
Link
As "James H" Sais, There is more interest, In this plugin. Then you may, Have realized. I see this as, A much needed improvement, To dbpro. I will keep using it regardless, But this will give it. The much needed push forward.

.:: Http://DeanWorks.Ca ::.
My software never has bugs. It just develops random features.
Back to top
Profile PM Email
Rudolpho
18
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 28th Aug 2014 01:51
Link
Thanks for your support GreenDixy, it is nice to hear

As an update of my progress I've been working on making world transform matrices available to the shaders in a better way.
This will ultimately lead to the removal of the rather intrusive syntax where per-instance data like transforms appear as part of the vertex shader input. Also with this new approach, transform data will be accessible from all shader stages as an array indexable by the instance id. It is a significant bandwidth improvement to just have to forward a 32-bit instance ID from the vertex shader to other stages which may need to access transform data as opposed to forwarding the entire (512-bit) world matrix per vertex as it has previously been.
I have been meaning to do this for a while but finally got an unavoidable push to take care of it since the previously used vertex/instance buffer approach doesn't work with the newly introduced null mesh concept (basically a mesh which lacks any vertexdata and instead invokes the vertex shader a set number of times, moving the work of constructing the geometry entirely to the GPU. This should be useful for things such as particles and sprite rendering).
While I have determined that this different approach indeed works, I have yet to profile it to see if it will be more or less efficient than the previous approach. I'll write another update when I know for sure.


"Why do programmers get Halloween and Christmas mixed up?"
Back to top
Profile PM Email Website
Rudolpho
18
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 28th Aug 2014 15:07
Link
The instance transform data is now provided in a buffer and is accessed like so from any shaders:



The instance ID can be requested from the input assembler by adding a uint using the SV_InstanceId semantic to your vertex input structure.

This change alone actually seems to run slightly slower than the previous approach when used with *large* amounts of instances (ie. when there is much data to send to the GPU and similarly much data to read from the GPU), however the ability to now access the transforms from any shader stage (most importantly the geometry shader) without having to pass the entire matrices along with the per-vertex data outweighs this and has the potential of increasing the execution speed beyond what little slowdown the reading of a dynamic buffer as opposed to a standard buffer causes on the GPU side.
For scenes which use less instances there seems to be a slight speed increase on the whole with this new approach.

As a reference, the foliage demo application runs at 114 FPS for me from the default viewing position at startup with the old approach of copying the entire world matrix from each of the 1.024 million grass instances; before the change my FPS here was 116. However when only transfering the instance ID to the geometry shader for each vertex instead of the full transform, my FPS rises to 117. Not much of a change, granted, but this new approach
1) looks more "correct" in the terms of writing shaders and
2) allows for greater extensibility; most notoriously you'll be able to retrieve the world matrix of a null mesh.


The bad news about this is that it breaks compatibility with all shaders that use the old INSTANCEWORLD / INSTANCEWVP semantics in their vertex shader input structures. Changing this isn't a very big endeavour however. I'm currently working on updating all previous example shaders to accomodate for this change.

Finally, I have a job interview tomorrow night so I probably won't be able to work much on this until the weekend, which is also going to be a bit busy for me. But stay tuned


"Why do programmers get Halloween and Christmas mixed up?"
Back to top
Profile PM Email Website
Chris Tate
DBPro Master
15
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 28th Aug 2014 17:21 Edited at: 28th Aug 2014 17:33
Link
Good luck with job position.

I look forward to creating some complex shaders for your plugin; but I will have to learn how to walk before I can run. Currently I am more experienced with shader models 2 and 3; and will need some practice before getting familiar with model 5 (and 4 I guess).

It is going to be interesting to learn how one replicates rendering on different hardware using different models in the same application.

One of my most least understood shader techniques I am most interested in achieving is volumetric shading;



I look forward challenging myself to getting these kind of effects working in Ziggurat.

Back to top
Profile PM Email Website
Rudolpho
18
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 31st Aug 2014 14:01
Link
Haha, thanks... unfortunately it turned out once I got there that "something had come up" and they were unable to come conduct my interview -.-
Very annoying considering I had about 2 hours worth of travel time single trip; you'd think they could've at least given me a call to tell me it was off but apparently not...
Will see if they'll get back to me on monday about any follow-up or if that was just their fugly way of saying "screw you, the position's been filled but we won't tell you that to your face". Oh well, I shouldn't rant about that, just really annoying after preparations and everything

I don't think there are any huge differences between the core functionality (on the vertex- and pixel shader stages that is) between SM2/3 and 4/5. Some declarations are different such as manually specifying registers but I believe this is mostly a result of the Effects Library (the thing that allows you to define techniques and passes in your HLSL code) being gone.
Of course you have new shader stages which means things can be implemented in different ways than before, or need to take further steps into account. This, like so many other things, becomes a habit with time (at least it did for me). I won't say there isn't at least 90% left of things you can do with shaders that I'm currently completely oblivious to though; it would be really interesting to see what a real shader wizard like Green Gandalf or Evolved could achieve using SM5. All other things aside it does things like dynamic branching a lot better than SM3 and also supports a greatly increased number of resources and instructions.
If you put your mind (and lots of time) to it, I have little doubt truly awesome things could be created. That columetric rendering looks really cool for instance, but I won't claim to have much of an idea as to how it is achieved. Could it be as simple as a post-processing per-pixel trick? The memory and computation requirements for rendering it all as particles would sure be humongous :o


"Why do programmers get Halloween and Christmas mixed up?"
Back to top
Profile PM Email Website
Chris Tate
DBPro Master
15
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 23rd Sep 2014 20:45 Edited at: 23rd Sep 2014 20:47
Link
From your standpoint, would you say that the following function is well optimised, or lacks efficiency? Perhaps only one vertex layout is required for all similar objects?



Does there happen to be a way to test if an object exists? Or is this our responsibility?

Back to top
Profile PM Email Website
Rudolpho
18
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 24th Sep 2014 00:44
Link
The general approach is just fine, however...
Quote: "Perhaps only one vertex layout is required for all similar objects?"

Yes. You should re-use all kinds of resources whenever possible for the best performance. The reason for this is that my rendering engine attempts to sort objects in such a way that batches of objects (actually limbs) having the same states and shaders can be rendered at the same time, thus avoiding state changes and resource rebindings when possible, which removes some overhead.
As a matter of fact, shader techniques are used as a criterion in this sorting where objects having the same shader technique are always attempted to be grouped together unless they specify that they need special sorting modes (such as ones prioritizing screen depth which is needed for proper blending of transparent objects).

Because of this I would re-use the whole shader technique and vertex layout where possible. In your example I would set up a global reference to the vertex layout and shader techniques and just apply those in the ApplyDefaultShader function.


Quote: "Does there happen to be a way to test if an object exists? Or is this our responsibility?"

There are checks for resource validity that are performed when calling any function taking such a resource as an argument so that an appropriate error message can be shown if it isn't valid. However these routines are currently not exposed through the DBPro API. It could be added though.
The general idea is that the DBPro programmer should keep track of existing objects; the resources return actual memory pointers rather than an identification number so you will never be referring to things like "object 1" or "image 4" anyway. The upside to this is that you can store them in arrays and then remove elements from those as needed; functions that operate on a range of objects can then take such an array as an argument. This saves the hassle of looping over say all bullet objects which use id's 1000 - 2000, but at the current frame only 1000, 1002 and 1498 exist.


"Why do programmers get Halloween and Christmas mixed up?"
Back to top
Profile PM Email Website
Duffer
21
Years of Service
User Offline
Joined: 9th Feb 2003
Location: chair
Posted: 5th Oct 2014 12:03
Link
@ Rudulpho,

Meant to ask how this was coming along?

With sprites in DX11 does it handle sprite collisions as well as sprite priorities?

a long time dabbler with DBC and DBPro with no actual talent but lots of enthusiasm...
Back to top
Profile PM Email
Rudolpho
18
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 5th Oct 2014 16:49
Link
The would-be version 0.4 of the engine/plugin (which brings support for compute shaders and a set of general purpose buffer-type resources that can be used by shaders (compute as well as others) where traditional textures are unsuitable for memory storage) has actually been finished for the last month or so. What I've been stuck with is writing a "simple" demo program showing how to use compute shaders; I have thus far been unable to device a proper parallel sorting implementation that can be used to sort polygons by depth on the GPU. I'm currently using a parallelized mergesort which however yields terrible results (sorting 8000 quads at ~60FPS on a GTX 680 card) as the parallelism deteriorates towards the end when the sub-lists have to be merged into larger lists by fewer and fewer threads.
While there are descriptions of "sorting networks" that presumably solves this problem in a much more efficient way, they have proven very tricky to implement on the GPU due to requiring synchronization between nodes (threads) at varying points. The DirectCompute API only allows synchronization of full thread groups (or the entire GPU by issuing multiple dispatch calls) though, which means the problem domain seemingly needs to be broken down into a very particlular way to map onto the architecture. I could of course release the new plugin version without this demo application but it wouldn't sit right with my sense of honour. I am hoping I will eventually be able to solve this and in the process maybe even publish some much needed explanations of what and why things have to be done to achieve it in the process.

Quote: "With sprites in DX11 does it handle sprite collisions as well as sprite priorities?"

There is no such functionality present as of yet. I am planning to eventually add 2D physics handling to the engine through the Box2D library, if its license permits redistribution.
For the time being you can implement a simple "are sprites overlapping" function by checking if any corner of one sprite lies within another. This is basically the full extent of the sprite collision commands built into standard DBPro where only the bounding rectangle of the sprites are checked. Whether the sprites "hit" each other can be determined by storing the last overlapping flag and if it was false in the previous frame and is true now, the sprites have just hit.
Writing a function like this is very simple so I can add it directly to the plugin for version 0.4 once I solve that inglominous sorting problem.


Meanwhile I've also been contemplating an extensible lighting system for 3D objects as a result of Chris Tate's mentioning of that a while back. I believe I have an idea for how to solve this in such a way that it can be incooperated even when using custom shaders; I will start looking into implementing this once version 0.4 is released.


"Why do programmers get Halloween and Christmas mixed up?"
Back to top
Profile PM Email Website
Chris Tate
DBPro Master
15
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 5th Oct 2014 17:45
Link
Sounds cool!

Back to top
Profile PM Email Website
Rudolpho
18
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 20th Oct 2014 01:09
Link
Version 0.4 is finally released and can be downloaded from the opening post or here.

This version brings support for DirectCompute and compute shaders, making the plugin now supporting the entire gallery of shader types present in DirectX 11. The number of exported functions by the plugin are now in excess of 750, making a multi-plugin solution a requirement in the not so distant future since the DBPro compiler can only read 898 string table entries per plugin.
Moreover a new class of shader resources, buffers, are available for all those situations where a texture isn't suitable and a cbuffer isn't large enough. Using buffers you can store arbitrary amounts of completely arbitrary data (arrays of primitive types, arrays of custom structs, or just plain memory blocks) that can be read by your shaders (as well as written to by compute and pixel shaders). With the introduction of such buffers I have chosen to move the transform data that was previously supplied as part of the input vertex data into a reserved Transform buffer that is indexed by the instance id (this can be requested by the vertex shader from the input assembler stage; see the example projects for how this is done). More than making your shader code more aesthetically pleasant (ie. "readable") this change allows transform data to be accessed by any shader stage instead of having to be forwarded from the vertex shader through each shader stage as was the previous case, thus greatly decreasing bandwidth usage in such situations.
Unfortunately this breaks backwards compatibility with the earlier versions; all shaders (the default ones as well as those used in the example projects) have been updated to use the new system. Take a glance at them to see the change; it isn't a particularly big undertaking to update a shader written for the old system to use the new one.

Buffers and textures share the same resource registers on the GPU; for this reason textures will always be bound to the first 16 such registers by the Ziggurat engine. You can now also bind up to 8 buffer resources to everything you can bind textures to (objects, limbs, sprites). These will use registers t16 through t23. Registers t24 and up are reserved for use by the Ziggurat engine.
With compute shaders the same overall limitations don't apply as with the rendering shaders however; here you can have 64 textures / read-only buffers per compute shader. Take note that in the case of the compute shader you can assign whether to bind a texture or a buffer to any such register yourself. Compute shaders can also have up to 8 writable "output" buffers (or textures for that matter) using DirectX 11. With DX10 only a single output resource is allowed at any one time.
You can also write to a buffer / texture from a pixel shader; in this case the buffer / texture shares output registers with render targets. Since there is always at least one render target per camera you can not use this output functionality in DX10 mode. The advantage to this kind of writing as opposed to the standard approach of writing to a render target is that you can write to any location within the buffer / texture.

Apart from this, a special "null mesh" resource is now available for use. This is essentially a mesh which contains no vertex or index data but is rather used to invoke its associated vertex shader a certain number of times, leaving it to the GPU to construct the actual geometry on the fly.


There are also two new example projects included demonstrating these new concepts;
○ Screen Quad demonstrates the creation of a screen quad that perfectly covers the screen, generated by a vertex shader using a null mesh. This example also demonstrates multi-camera rendering with object masking and a simple blurring post-process shader applied by means of a pixel shader to the afforementioned screen quad.

○ GPGPU Particles demonstrates the creation of a simple particle system that is handled entirely by the GPU through compute shaders.
It also features a null mesh for which compute shaders set the number of control points ("vertices") to render, and its vertex and geometry shaders then expand this into camera-aligned quads representing each particle in realtime. In addition to this it shows how to perform parallel sorting on the GPU to sort all particles by depth for proper blending of transparent pixels.



The above being the main new features in version 0.4, there have also been various bugs identified and fixed such as the DBPro application sometimes crashing after displaying an error message in earlier versions, DX11 GET PROJECTION MATRIX accidentally returning the view matrix instead and various string table entries being incorrect resulting in certain functions not being readily available from DBPro.
I have also added a DX11 IS SPRITE OVERLAPPING function that checks whether two sprites are currently overlapping and a set of DX11 «???» EXISTS functions for checking whether resource references are valid as requested by Duffer and Chris Tate respectively.


"Why do programmers get Halloween and Christmas mixed up?"
Back to top
Profile PM Email Website
Chris Tate
DBPro Master
15
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 20th Oct 2014 18:33 Edited at: 20th Oct 2014 18:51
Link
I will do my best to test out the new version. I hope you get the recognition and credit you deserve for all of this work. You should set up a page to receive some donations; unless you have other plans.

I want to see one day, a forum filled with DX11 games, screensavers and a flourishing community centered around this movement. Fingers crossed.

Back to top
Profile PM Email Website
Rudolpho
18
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 21st Oct 2014 13:03 Edited at: 21st Oct 2014 15:12
Link
Thank you.

I might do that, although I have a distinct feeling involving any type of donations / payment at this stage will probably just deter people from taking an interest. As it happens Kickstarter recently opened up for projects based in Sweden earlier this month so I might look into that. It's hard to set any definite deadline as to the completion of this project though (like I feel should be provided if you went down that route); it evidently isn't all that unlikely to hit a brick wall that takes a very long while to find a way over every now and then

Back to top
Profile PM Email Website
Sph!nx
15
Years of Service
User Offline
Joined: 3rd Dec 2008
Location: The Netherlands
Posted: 27th Oct 2014 14:30
Link
(Tagging in)

Great work. Good luck!

Regards Sph!nx
Back to top
Profile PM
Arbrakan
13
Years of Service
User Offline
Joined: 10th Oct 2010
Location: Geneva
Posted: 2nd Nov 2014 17:28
Link
Awesome work !

Back to top
Profile PM Email
Rudolpho
18
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 8th Nov 2014 00:13
Link
Thanks

Since I have a deadline for a paper at the end of this month, work on this project will have to take a backseat until the beginning of December.
What has been done since the last update mainly revolves around preparing the engine for the to-be lighting system, which has mainly meant some updates to shaders;
these can be compiled directly from memory as opposed to only from files now (ie. the shader source can be provided as a string and compiled from that at runtime), it is also possible to do offline compiling of shaders and then load the precompiled byte code at runtime, which can save significant loading times with complex shaders.
Moreover a custom shader include handler has been implemented, allowing specific short-hand directories to be searched for include files to be added (akin to a %PATH% variable for shaders), as well as registering certain include names to map directly to a shader source (file or string).
The idea with this is to provide easy access to system shaders through means like #include <zig-lighting>, which will include the default lighting interface, rather than having to keep track of an external hlsl file to be included here. It also allows the system shaders to always be up to date since they are stored in the plugin binary itself.

Besides the lighting system, I intend to address the error management system for the next release, with the hopes of making all errors recoverable from DBPro (of course the actual recovering would be up to the DBPro programmer, but it definately offers better possibilities than the current "display error message and terminate"-style error handling).

Back to top
Profile PM Email Website
Arbrakan
13
Years of Service
User Offline
Joined: 10th Oct 2010
Location: Geneva
Posted: 9th Nov 2014 17:35
Link
Thanks for the news! Good luck with your paper.

Back to top
Profile PM Email
The Zombie Killer
13
Years of Service
User Offline
Joined: 27th Mar 2011
Location: Gold Coast, Australia
Posted: 10th Nov 2014 07:32
Link
Out of curiosity, is there any way to combine this with DBP's built-in ODE physics?
Back to top
Profile PM Email
Rudolpho
18
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 10th Nov 2014 12:26
Link
I am not really familiar with the ODE wrapper available for DBPro, but from the looks of it it reads object data from DBP object id's. If this is indeed the case, then sadly no, it will not work because my engine uses its entirely own object system of which any third party plugin is unaware.
If it is possible to provide collision data yourself to the ODE plugin it should be possible to use it however (things like "make a box collider with these dimensions and at this position"). Unfortunately I cannot find any documentation for these physics functions other than a keyword file and the export table of the plugin itself, but looking at those it seems like this kind of data cannot be manually set.

So my guess would be that it will not work out of the box but rather require the ODE plugin to be recompiled to sample object data from the Ziggurat engine rather than the DBP GlobStruct.

Back to top
Profile PM Email Website
The Zombie Killer
13
Years of Service
User Offline
Joined: 27th Mar 2011
Location: Gold Coast, Australia
Posted: 10th Nov 2014 12:42
Link
Ah, shame. I do believe there are functions to scale the ODE objects however, so I guess you could create one and scale it to the dimensions you need.
Thanks for the answer anyway, I appreciate the response.
Back to top
Profile PM Email
Matty H
15
Years of Service
User Offline
Joined: 7th Oct 2008
Location: England
Posted: 2nd Feb 2015 12:21
Link
Hi Rudolpho,

Was it you who requested the source code for Dark Dynamix? Sorry if it was not you, if it was could you email me again, thanks.

Matty

Back to top
Profile PM Email
Rudolpho
18
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 6th Feb 2015 11:36
Link
Hi, yes I think I did that a while ago, it had something to do with the fact that it would crash upon being manually loaded by a C++ application running the DBPro dll libraries. Since that project eventually got shelfed due to TGC seeing it as a possible means of circumventing the licensing of third party plugins I have no immediate need of it anymore. However if you're willing to share it I would of course be interested to see the source still so
I'll send you another e-mail.


As for the current status of the DX11 engine I have been pretty busy with other un-related things since my last update. I have worked on it but only manage to get in an hour there and another there every so often so there hasn't been any significant progress.
What has been done is the implementation of a start of a lighting system. This seems to work well and currently supports an arbitrary amount of point lights (spot- and directional lights to come). The lighting works by providing a library of shaders containing utility functions; these are stored in the plugin themselves as resources and can be included by any shader used with the plugin without the need of including the actual shader files on disk with all projects. The whole lighting can then be applied to a custom pixel shader simply by calling a function from this lighting library that expects a world-space location of the pixel, its diffuse (pre-lighting) colour and, optionally, a normal (that can be sampled from a normal map if you so chose).
While testing this lighting system a set of most elusive bugs in the mesh animation system came to my attention however - certain animations will cause incorrect vertex displacement and unmatching key frame timings.
I have finally managed to track down and resolve most of the key frame timing issue in the last week but there are still the displacement issues to be straightened out. Hopefully this will be easier now that I've found the symptoms were in fact caused by (at least) two different underlying problems. Once I get this solved I will try to post a simple demonstrative video of the lighting system thus far. As said I have a lot going on in my life at this point in time so I cannot say when this will happen but hopefully it will be somewhat soon.

Back to top
Profile PM Email Website
Star Vitebsk
16
Years of Service
User Offline
Joined: 18th Oct 2007
Location: Belarus
Posted: 4th Mar 2015 08:03 Edited at: 4th Mar 2015 08:04
Link
does not start here gives this window



VitebskStar@tut.by
icq: 157980031

Attachments

Login to view attachments
Back to top
Profile PM Email
Rudolpho
18
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 4th Mar 2015 18:50
Link
Upps, I was under the impression it would time out tomorrow and have thus been hard at work to put together a new version in time for that over the last few days.
Luckily I was just about to post it, so see the next post (which should be up within the next 15 minutes or so) for a presentation of it.

Here's a direct link from where you can download it.

Back to top
Profile PM Email Website
Rudolpho
18
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 4th Mar 2015 19:35
Link
Version 0.4.5 is released and can be downloaded from the opening post or here.

This release is essentially just a bug fix for the animation system that was apparently broken and could cause severe mesh displacement with certain objects. The cause for this was most elusive and to solve this the whole animation system eventually had to be rewritten from scratch. The DBPro interface to it is the same however, with some additional optional function parameters and extra functions thrown in.
I believe that this rewrite has resulted in a generally more stable and easier modifiable system. Apart from this it also facilitates some new features that weren't present before - animations can now be played in reverse, you can play a certain section of an animation (between two set frames) without the explicit need to create a new animation instance for this and animations can be stopped and then either restarted or resumed from their last state. The current frame to play can also be set manually, a bug where the DX11 GET ANIMATION FRAMES PER SECOND function didn't work has been resolved and the transition when changing from one animation to another on an object is smoother. The new system is also more suitable for possible future shader based animation support.
The Skeletal Animation example has been slightly updated to better correspond to the new animation system, but all previously written code using the old one should still work, although...
There was a bug in the old animation system causing it to offset by one frame too much when extracting sub-animations from a master animation sequence. Because of this you may have to adjust the frame range for any animations that were set using the old system.


As has been previously mentioned, work since the last update has also been put into a default lighting system as well as error management. This is an ongoing undertaking although it isn't reflected in this release since I want to complete it and ascertain its feasability first. I will also have to start splitting the functions into two or more plugins because the DBPro compiler only scans the first 899 functions in any single plugin, which will be reached with a mere handful more functions now.


Known issues:
Certain objects will appear as much smaller than they were with the previous system. The cause for this needs to be further investigated, which is next on my to-do list. If you happen upon such a model you can use DX11 SET OBJECT SCALE to resize it. Its bounding volumes will reflect the altered size so it will still be properly culled.

Back to top
Profile PM Email Website
Duffer
21
Years of Service
User Offline
Joined: 9th Feb 2003
Location: chair
Posted: 8th Mar 2015 10:35
Link
@ Rudulpho,

This is a fantastic effort on your part! Keep up the great work.

Can't wait for implementation of Physics.

Wonder whether TGC would consider incorporating this in to the post-GamesGuru-release final fanfare version of DBPro...

a long time dabbler with DBC and DBPro with no actual talent but lots of enthusiasm...
Back to top
Profile PM Email
Rudolpho
18
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 9th Mar 2015 21:04
Link
Thank you Duffer, I really appreciate it
Physics will be a major part, essentially its own engine tied in with the rest so it will probably take quite some time, but I'm looking forward to it too.

Quote: "Wonder whether TGC would consider incorporating this in to the post-GamesGuru-release final fanfare version of DBPro... "

That would be awesome, you never know ^^
Though all the hushing and shushing about any possible future DBPro upgrades seems a bit ambigious... Well, we'll just have to wait and see I guess.

Back to top
Profile PM Email Website
Dimis
12
Years of Service
User Offline
Joined: 12th Jun 2011
Location: Athens, Hellas
Posted: 13th Mar 2015 18:11
Link
It will be a very bad thing, if we get no future upgrades, but in case there is any future in DBpro, then TGC should consider incorporating your plugin. Maybe DBpro will no look so outdated with it. Let's hope TGC will not let DBpro die...

Back to top
Profile PM Email
Naesa
18
Years of Service
User Offline
Joined: 21st Dec 2005
Location: Sweden
Posted: 29th Mar 2015 18:05
Link
Quote: "It will be a very bad thing, if we get no future upgrades, but in case there is any future in DBpro, then TGC should consider incorporating your plugin"


They definitely should! This plugin is what might save DBpro from extinction.
Back to top
Profile PM Email
Guido Italy
18
Years of Service
User Offline
Joined: 25th Dec 2005
Location:
Posted: 29th Mar 2015 20:32
Link
yes yes !
Back to top
Profile PM Email Website
Rudolpho
18
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 31st Mar 2015 12:47
Link
Thank you for your support

I'm currently stuck on an annoying shader issue (if only there were more thorough documentation on that readily available...) since a few days but hopefully I'll be able to work it out and get back to getting more productive work on this done soon enough.

Back to top
Profile PM Email Website
Naesa
18
Years of Service
User Offline
Joined: 21st Dec 2005
Location: Sweden
Posted: 31st Mar 2015 19:26
Link
That sounds frustrating. What kind of a shader issue?
Btw, check your messages
Back to top
Profile PM Email
Rudolpho
18
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 31st Mar 2015 21:26
Link
Haha, now that's embarassing... I always expected you would get some kind of notification for having new messages, turns out I have unread ones since last July that I didn't know a thing about...
So thanks for pointing that out Naesa!

Quote: "What kind of a shader issue?"

At the moment it is about supporting specular highlights for point light sources. Any examples I can find only seem to use directional lights (for simplicity no doubt) but you'd think that the approach should be similar (ie. get the light direction by taking the world position of the rendered pixel and subtracting the light source's position from it and normalize the result). That doesn't seem to be the case though, or I must be missing some critical point.

Back to top
Profile PM Email Website
Rudolpho
18
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 13th May 2015 18:10
Link
There has been a relatively long period since the latest update on this project.
While version 0.5 is still a bit off into the future I thought I would showcase the default lighting system I've been working on thus far to show that the project is still alive.


The default lighting system is, as the name implies, what will be used by default to render your objects unless you tell it to do otherwise. The resources used by the lighting system is made available to any custom shader through library includes and you are free to use this as a building block to create your own lighting system on top of. What is available are arrays of point, spot and directional lights, with member elements such as light colour, intensity, range and falloff. More specific data such as direction and cone angle is available for the light sources that use those.
It is also very easy to incorporate the default lighting system with your own shaders that do not handle lighting themselves; merely include <z-light> and call ComputeLightContribution() from your pixel shader.
This takes a couple of arguments (the pixel's world position, it's normal vector and the direction that the rendering camera is looking at the pixel, plus optionally a specular power factor) and returns any diffuse and specular light contribution from all relevant light sources at that pixel. You can then combine this data with the pixel's diffuse colour / etc. and output it from your pixel shader.

Back to top
Profile PM Email Website
Gervais
20
Years of Service
User Offline
Joined: 11th Mar 2004
Location: Canada
Posted: 16th Jul 2015 23:08
Link
Hi Rudolpho,


I would like to know how well this new plugin will interact with the existing plugin like dark cloud and Blitzwerks Terrain and other function of DBP like the memblock
Back to top
Profile PM
KISTech
16
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 18th Jul 2015 23:14
Link
Keep up the good work. I'll be following along to see how it goes.
Back to top
Profile PM Email Website
Rudolpho
18
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 22nd Jul 2015 22:59
Link
Quote: "I would like to know how well this new plugin will interact with the existing plugin like dark cloud and Blitzwerks Terrain and other function of DBP like the memblock"

The term "plugin" in the DBPro context has come to be more or less synonymous with an extension of the "core" DBPro library. The aim of this project is however rather to replace that core library.

By generalizing, other "extension type" plugins can be said to be of one of three types (of course it may belong to more than one of these types also):
• DBPro Core-dependent - these types of plugins are dependent on and access the core DBPro library. For example any physics plugin (DarkPhysics, DarkDynamix, Sparky's Collision Plugin, etc.) will fall in this category because they make use of object and mesh "id's" as referenced from DBPro. The Extends plugin is another example of a plugin in this category.
• D3D Device-dependent - these types of plugins use the DBPro library merely to gain access to its Direct 3D Device (ie. the DX9 interface) that it may then do things with. Examples of plugins belonging in this category are the D3D Plugin and quite likely BlitzTerrain. Both of these plugins likely make further use of the core library as described above in order to create resources that will then be made available to DBPro as object id's, images, etc.
• Independent extension - these types of plugins add completely new functionality that is not dependent on DBPro or the D3D device. Examples of plugins belonging to this category are most of the Matrix1 Utilities libraries, Dark AI (the DBPro programmer has to manually control DBPro resources in accordance with the AI simulation) and the various Windows GUI libraries (BBBGui, BlueGUI, etc.).


Now because my engine for all intents and purposes replaces the standard DBPro engine (not literarily true; you can use both at the same time but there would be little point in that as far as I can imagine), its internal structure is different from that of the DBPro core and as such only the third extension plugin category can be assumed to work out-of-the-box with it. However, much like how your plugins can get a pointer to a structure containing globals (including the D3D device pointer) from the DBPro core, you can retrieve a corresponding pointer from the DX11 plugin as well. They do not match 100% though, nor do they strive to (there are certain things that are just handled in a different way between my engine and the DBPro engine), so there would likely have to be some modifications made, but should the author of a third-party plugin decide to support my engine as well as / instead of the DBPro engine, the tools are available.
Likewise there is quite a difference between the D3D9 Device and the D3D11 Device (which has actually been further divided into a device and a device context) so any plugins using that cannot assume to work without tweaking the code to account for the DX11 changes either.
Unfortunately this breaking of direct-compatibility is pretty much necessary when writing a completely new engine such as this, because that's what it is - it strives to use similar concepts as standard DBPro, such as limbs, objects and meshes, to feel familiar but under the hood the implementation is quite certainly different between the two.

Now on the other hand, I plan to make some "core game engine" functionality available directly through my engine that wasn't in DBPro and thus required third party plugins to account for this.
For example, the current version of my engine provides comparable functionality to that found in the Enhanced Animations plugin. Likewise, physics functionality through PhysX (such as that found in DarkPhysics and DarkDynamix) is also planned to be present in the base engine itself by default, as well as a extensible lightning system that isn't directly comparable to DarkLights but still should be quite more advanced than DBPro's default per-vertex lighting.

Regarding the particular question about memblocks, their functionality exists through resources known as buffers in the DX11 plugin. Actual memblock support could be added, however the intent is that my engine should be entirely decoupled from the DBPro engine itself such that you eventually won't need to initialize the latter to run the former (ie. you have to have the DBPro engine sit in the back doing nothing but requiring DirectX 9.0c - as you can imagine this isn't a desireable situation ).


Quote: "Keep up the good work. I'll be following along to see how it goes. "

Thank you!

Back to top
Profile PM Email Website
Ortu
DBPro Master
16
Years of Service
User Offline
Joined: 21st Nov 2007
Location: Austin, TX
Posted: 12th Aug 2015 00:12
Link
meant to tag in sooner, but really awesome work here man.

Back to top
Profile PM Email Website
Star Vitebsk
16
Years of Service
User Offline
Joined: 18th Oct 2007
Location: Belarus
Posted: 20th Aug 2015 12:35
Link
How about directx 12 ?

VitebskStar@tut.by
icq: 157980031
Back to top
Profile PM Email
Rudolpho
18
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 23rd Aug 2015 11:04
Link
Thanks Ortu

Quote: "How about directx 12 ?"

Not any time soon, if at all. Since you need Windows 10 to be able to use it I don't think there will be that big of a percent of computer users who would have any use of it for a while yet. As for myself I plan on sticking with Windows 7 for the foreseeable future after not being overly impressed with what I saw of the technical preview of Windows 10. That said, in due time maybe. But I have no plans of it at all at the moment.

Regarding the development of this project it has been a bit stalled recently due to various circumstances.
I do hope to continue working on it come this fall though.

Back to top
Profile PM Email Website
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 28th Aug 2015 17:32 Edited at: 28th Aug 2015 19:11
Link
I've just been given a gentle nudge by SW3DG to have a proper look at this - and, WOW!, you've achieved a lot. Well done.

Every demo worked - once I realised I needed to use the "high performance" NVIDIA GFX card on my two card laptop .

The only problem I've noticed is that the demos run in a slightly small window, i.e. 1591x877 instead of 1600x900 (which is also the default screen setting on my laptop). Any idea why? [Edit2: Just discovered that problem is caused by the "Hidden" screen type set in the project properties. Changing that back to my usual fulldesktop setting cured the problem. I've never seen the "hidden" screen type before. What is it? ]

I'm very much looking forward to giving this a try with my own demos. The displacement, tessellation, and instancing demos were particularly impressive. [Edit Oops, I meant foliage not tessellation. No idea where that came from. ]

Edit3 Done some more testing and was puzzled by the small unreadable blurred fonts on most/all of the demos. I tried changing this



to this



and, Hey Presto!, crystal clear graphics and text!



Powered by Free Banners
Back to top
Profile PM Email
Rudolpho
18
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 29th Aug 2015 18:52 Edited at: 29th Aug 2015 18:54
Link
Quote: "I've just been given a gentle nudge by SW3DG to have a proper look at this - and, WOW!, you've achieved a lot. Well done."

Thank you, that means a lot coming from you!
I recall your posts being quite instrumental to me finally deciding to try my hand at (and make sense of) shader programming a few years back, so thanks again for that also

Quote: "The only problem I've noticed is that the demos run in a slightly small window, i.e. 1591x877 instead of 1600x900"

Hm, I have never run into this problem, but it is probably due to the desired window size exceeding the resolution of your monitor; the window will ordinarily be created such that the client area, ie. the actual part of the window that is being drawn to, excluding the borders, is of the desired size. This means that the actual window will be a bit larger. Still doesn't explain why it ends up smaller though, there is no code that should cause that. Maybe it automatically resizes to fit your screen?
The hidden display type causes the DBPro window to not be shown when running your program. I use this in the DX11 examples because my engine runs in its own window and the DBPro window would just sit in the back being black (unless you use the standard DBP function to render to that one also), would occupy an extra slot on the taskbar and your program would close if you were to close that DBP window. I cannot see why setting that display mode should have any effect on the other window, unless maybe them being created one after another causes a focus switch message that would prevent that auto-resize that I theorized about earlier (which of course is nothing but pure speculation). You could try double clicking the border of the (DX11) window two times and see if it makes any difference.
Edit: actually that shouldn't work since the window isn't maximizeable / restoreable by default.


As for the font being blurred, this is probably due to the window not fitting (with borders and all) on your screen and as such it gets slightly downscaled from its intended 1600x900 resolution. Setting the third argument to the DX11 INIT function to true will run it in full screen mode, thus bypassing the window borders and the taskbar and letting you use the full resolution of your monitor.
It might be an idea to set the window to be 1280x768 pixels or some other size that is smaller than your screen resolution if you want to run it in windowed mode; hopefully that should alleviate any visual artifacts


Quote: "I'm very much looking forward to giving this a try with my own demos."

I'm happy to hear it! Keep me posted on how it turns out

Back to top
Profile PM Email Website
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 31st Aug 2015 01:52
Link
Quote: "It might be an idea to set the window to be 1280x768 pixels or some other size that is smaller than your screen resolution if you want to run it in windowed mode; hopefully that should alleviate any visual artifacts"


Yes, that would work as well. Part of the problem was that I didn't realise it was trying to run in Windowed mode because I didn't know what "Hidden" was supposed to be doing. I think it's all clear now, thanks.

Quote: "Keep me posted on how it turns out"


I will.



Powered by Free Banners
Back to top
Profile PM Email
Back to top

Login to post a reply

Server time is: 2024-04-19 08:41:18
Your offset time is: 2024-04-19 08:41:18