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.

Dark GDK / Magic Particles Rendering To Texture on Object.... Working :)

Author
Message
Mista Wilson
15
Years of Service
User Offline
Joined: 27th Aug 2008
Location: Brisbane, Australia
Posted: 29th Aug 2009 12:08 Edited at: 31st Aug 2009 09:29
Hello All, Ive been working a little(among other things) on getting Magic Particles to render to a texture that we can texture to a 3D object, like a plain... to make the particles 3d..

I succeeded, and while I havent done much testing... the changes required were of the most simplistic nature.

Basically 1 function had to be changed and 2 gdk functions added...

The "RenderParticles" function I changed, so that i switches to the new image render target before rendering the particles, then switch bak to the original target at the end...

The other 2 commands were 1 to create a box to render the image to and the crucial :

dbMakeImageUsage(2000, 512, 512, 1);

The particles wont render to any kind of image other than one created like above.... I dont know why and I havent tested much so I may be wrong lol....

anyway, here are 2 screenies :

Alpha Level 255 :


Alpha level 25 :


3 GDK Objects with 3 Seperate sets of emitters : (0-8 matrix particles-centre 9-14 fire-left 15-34 fireworks-right)




The attachment to this post is the complete Magic Particles GDK Wrapper, with the changes I made to it....

Here is the Main.cpp where the ONLY changes there were made, were made...



If anybody wants to test it for me, I would appreciate some feedback as to if it works properly or not..... I only changed the render target quickly, so might have muffed something...

Hope this helps someone

PS. DEMO Exe in the attachment compiled with GDK 7.4 -- you will need at least GDK 7.3 to use this, I dont believe previous version had the appripriate image commands available....

Updated

I have made as many changes as I can to the setup of the wrapper. The render target function is now setup in a manner that allows you to render to multiple images if you choose, and also to specify the red, green, blue and alpha levels of the image. Combining that with GDK object's alpha mapping, making a see through 3d particle emitter is quite easy(for example fire doesnt have a black background in reality does it ? lol)

The RenderParticles Function is now setup to use be told which emmitter to render from and to... so you can render different sets of emitters to different images as I have no demonstrated in the demo attached to this post...

If anybody has any question please feel free to ask, I dont know much about Magic Particles itself, but I will help as I can in relation to using this.

If it ain't broke.... DONT FIX IT !!!

Attachments

Login to view attachments
chunks chunks
17
Years of Service
User Offline
Joined: 2nd Jan 2007
Location: ackworth uk
Posted: 29th Aug 2009 18:36 Edited at: 29th Aug 2009 20:29
works great well done mista , only problem i can see is if u try to use dbsetobjecttransparency() it won`t work the black stays black ,which is a shame cos havin fireworks and such needs to be transparent , mabey a shader will do it or the render states .

well done again .

chunks

:EDIT: all you need to change for transparency is this line
device_3d->Clear( 0, NULL, D3DCLEAR_TARGET | D3DCLEAR_ZBUFFER, D3DCOLOR_COLORVALUE(0,0,0,0), 1.0f, 0);

note the color values .

attached is the project with transparency.
chunks

nvidia geforce 9500gt + amd athlon 64
windows vista ultimate.

Attachments

Login to view attachments
Mista Wilson
15
Years of Service
User Offline
Joined: 27th Aug 2008
Location: Brisbane, Australia
Posted: 29th Aug 2009 23:48
yep tahts right.... the line there is added to clear the image each loop, if you dont, the the iamge looks like a camera with no backdrop rendering.... which is essentially what the image is, a render target for the particles lol

I pasted the line from some other code of mine and changed the colorvalues. The reason was mainly so that it was easy for people to understand what was happening.

I do plan to add some other features, the post here was kind of cause I was excited about it lol, the changes to make, are so dam simple im surprised that someone else didnt notice it before me lol(I dont actually use MP for anything myself at the moment, but it sure looks cool)

Im planning on adding some paramaters to the renderparticles function to enable the user to set the background color(another reason I left the values in clear where they were, its also the bahaviour of the wrapper demo by its own programmer, so I didnt feel I should change it's original behaviour too much .. if you have a look at the original wrapper, it actually is clearing the device to black using a GDK command dbClear(0, 0, 0); each loop, I just removed that command and cleared the DX device manually lol, its easier and quicker... lol) and the alpha level...

Im not going to go too overboard though, as the Magic Particles guys are working on a new version that is supposed to be in 3D natively, I have no idea of their progress or anything, but this technique could be used temporarily or in the mean time to achieve something similar... With the particles rendering to an image, you can do pretty much whatever you like with it.... it is just a GDK image, you could just paste it in the loop rather than texture it if you wanted too... you could also make the render target another camera rather than an image if you wanted...

It DOES have a few drawback though.... lol

So far, its using a single image for a single effect(img 2000)... but what if you had 10 different effects ?

The answer would be to add some parameters to the RenderParticles() function to select the image number that you are working on, to be able to send different particle/emitters to different images you could add a parameter to pass the emmitter groups by reference or something.

You could even get tricky and write different render functions for different emmitters, depending on what they need, some to images, some to cameras...

If it ain't broke.... DONT FIX IT !!!
chunks chunks
17
Years of Service
User Offline
Joined: 2nd Jan 2007
Location: ackworth uk
Posted: 30th Aug 2009 11:59
Quote: "you could also make the render target another camera"


I would like to see how this is done , because i was asked before to make the zparticles plugin render to different cameras but i couldn`t figure it out , what you can do in gdk you can usually do in a dbpro plugin .

chunks.

nvidia geforce 9500gt + amd athlon 64
windows vista ultimate.
Mista Wilson
15
Years of Service
User Offline
Joined: 27th Aug 2008
Location: Brisbane, Australia
Posted: 30th Aug 2009 13:27
Hey Chunks -

Im sure that it's possible, although after having thought about it, sending it to a camera versus an image at the end of the day, might not be an advantage and as far as directX is concerned not too different, above, all I basically did was turn the image into a camera render target, so its sending DX camera data to the image instead of to the camera.

The function just stores and swaps the render target from the camera's render target to the image's render target and back again, to put it simply. As far as DirectX is concerened there is no difference between the render targets.

If you are interested, there are some methods to grab the GDK camera info to use with DX code, they are from D3DFunc 3.7.1 DBPro Source Code and you can find them either there or in my port of that to GDK 7.3+ , just search D3DLIB in the GDK forums. There is a data structure that represents all of the info the GDK camera can have, like render targets and FOV, transforms etc.. you fill it with the command :

void* dbGetCameraInternalData(int iCamera);

the return from that function fills the data structure, you can see how it works in D3DFunc.

From there, it shouldnt be too difficult to extract the camera's render target and swap Magic Particles in the same way in the same way I did above...

Sorry I know thats a little long winded, if I havent been clear enough on something please ask and ill try to explain better.

Hope this helps.

If it ain't broke.... DONT FIX IT !!!
chunks chunks
17
Years of Service
User Offline
Joined: 2nd Jan 2007
Location: ackworth uk
Posted: 30th Aug 2009 18:16
cool thanks i will take a look at the lib you made , see if i can port the zparticles plugin to gdk much better than magic particles you have a lot more options to control the particles .

chunks.

nvidia geforce 9500gt + amd athlon 64
windows vista ultimate.
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 30th Aug 2009 21:18
MISTA is THE MAN!

after his incredible work on making Shaders work faultlessly in GDK, he comes up with this Miracle!

I have waited for many weeks for the Magic Particles guys to do this "fix"!!!

Would it be possible for someone who has good knowledge of magic particles and gdk to make a small demo and show how you can render 2 (or more) magic particle effects at once?

thanks guys
chunks chunks
17
Years of Service
User Offline
Joined: 2nd Jan 2007
Location: ackworth uk
Posted: 30th Aug 2009 22:23
I might have a go , some of it needs wrapping up into functions so its easier to use cos the main loops a bit of a mess ,give me a couple of days and i will see what i come up with.

chunks

nvidia geforce 9500gt + amd athlon 64
windows vista ultimate.
Mista Wilson
15
Years of Service
User Offline
Joined: 27th Aug 2008
Location: Brisbane, Australia
Posted: 31st Aug 2009 00:53
I dont know the Magic Particles API at all, my changes were all related to the DirectX rendering process but I dont think it would be all that hard.

Im pretty sure though, by looking at what is happening in the program as it is, all you would need to change would be to add a parameter to the RenderParticles() to tell it which emmitter/s it is rendering, whether you do that with a set of integral flags and code logic or by passing a pointer to the emitter/s would be upto you.

The rest of the code is pretty much related to the API and is all Object Oriented and wrapped into classes and functions as it is. I dont think there would be much that you could do to wrap it into further functions or that there would be much point to putting your time into it(time is a valuable commodity these days lol). The API needs to be told to go through the folder and load all of the .ptc(magic particle) files it finds, and to load their textures, it sets up all of the variables that it needs to run, and thats all that it does really... it then drops into the main loop, where it just cycles through and updates the particles and then sends them to the renderer.

@bjadams - Cheers for the kind comments Ill take a look at making a little demo with more than 1 particle type in it(if chunks hasnt by the time get around to it anyway lol), probably just something simple though as like I said, i dont know their API at all and would probably wreck their wrapper if I fiddled too much lol..

If it ain't broke.... DONT FIX IT !!!
Mista Wilson
15
Years of Service
User Offline
Joined: 27th Aug 2008
Location: Brisbane, Australia
Posted: 31st Aug 2009 09:34
@bjadams - Check the top post mate I had some spare time this arvo, daughter went shopping lol, so i stuck together a few changes to the functions to allow them to be used to render multiple sets of emitters to different images.

The main.cpp file is where all the changes have been made, they are all pretty straightforward, but if you dont get any of it, just ask, I dont think I commented on the newer changes too much..

ps. sorry for the double post

If it ain't broke.... DONT FIX IT !!!
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 31st Aug 2009 11:46
Mista = GOD of GDK!

I agree with Chunks, there is a lot of code & loose functions here and there, I think that the system deserves to be cleaned up a bit furthur.

Also I noticed that the systems fetches file after file in the ptogr directory until it loads the proper ptc. Isn't this a waste of processor time:



I replaced that code with this:



What do you think? Ofcourse you need to know the name of the ptc file, but I suppose you would know that anyway!

Also what is the TEMP FOLDER being used for? There's a lot of code there too...
Mista Wilson
15
Years of Service
User Offline
Joined: 27th Aug 2008
Location: Brisbane, Australia
Posted: 31st Aug 2009 11:50
Have a look at my newest code .... it replaces that function aswell lol...

If it ain't broke.... DONT FIX IT !!!
chunks chunks
17
Years of Service
User Offline
Joined: 2nd Jan 2007
Location: ackworth uk
Posted: 31st Aug 2009 16:37
Nice work mista , its now cleaner and easier to use , and you saved me from busting my brain with this lol ,it`s great when someone gives up there time for a good community cause , i would have done it but it takes me a long time to understand things it would have took me a week to do that lol .

It might be usable enough to use in the gdk open source project , i will have to put it to techlord .



chunks

nvidia geforce 9500gt + amd athlon 64
windows vista ultimate.
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 31st Aug 2009 16:46
Thanks Mista.

Now I have finally understood how to control Magic Particles. i have integrated it in some projects and all seems to be working fine.

The only downside is that it kills fps on old gfx cards!
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 1st Sep 2009 15:51
can the texture be bigger than 512 x 512?

when i tried to change it i couldn't get any output
Mista Wilson
15
Years of Service
User Offline
Joined: 27th Aug 2008
Location: Brisbane, Australia
Posted: 1st Sep 2009 16:16
yeah, it can, thats just the size of the image I made in that demo... just change the dbMakeImageUsage command to use whatever res you like....

and there is another 2 variables that you need to set, to tell the MP manager what size it is rendering...

these are the lines :



You just need to change the above image creation and the "client_wi, client_he" variables.

The trick will come when you want to render differently sized images at the same time... there are acouple of ways you could do it... you could have multiple managers, you could change the variables inbetween the MP->Update calls.. or you could just use the image's UV data to position the rendered image where you wanted it(left side, right side, top etc) atm, they will render in the centre of the texture.

I encourage you to play with the different variables in the main loop and run the program to see what effects it has, maybe try to add some input commands to alter the values based on keypresses, then you can see the changes in real-time.

The thing to keep in mind though, is that you shouldnt need to change anything inside the actual wrapper itself, it's actually very well thought out and designed, in the way C++ classes should be, its self-contained and can be used and managed with no need to know or even look at the internals. All the changes that you should need to make can be done from inside the DarkGDK() block or the RenderParticles() function.

If it ain't broke.... DONT FIX IT !!!
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 1st Sep 2009 20:48
What is the TEMP FOLDER being used for in GetPathToTemp() ? There's a some registry code in there...
And what does the GetPathToTexture() function do exactly? Aren't textures included in the PTC data file?

I skipped these functions assigned temp_folder & texture_folder to "" and all still works fine!

const char* temp_folder=""; //GetPathToTemp();

const char* texture_folder=""; //GetPathToTexture();
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 1st Sep 2009 20:52
if i change the target render size to 256 it works.

if i change it to 1024 it doesn't work
Mista Wilson
15
Years of Service
User Offline
Joined: 27th Aug 2008
Location: Brisbane, Australia
Posted: 2nd Sep 2009 01:10
@bjadams -

Quote: "What is the TEMP FOLDER being used for in GetPathToTemp() ? There's a some registry code in there...
And what does the GetPathToTexture() function do exactly? Aren't textures included in the PTC data file?
"


The TEMP folder is the path to the windows temporary files folder, its a folder that windows looks after, and stores the system's temporary files there, Magic Particles uses texture atlases for it's particle textures, and it needs to build the atlas before it can be used... Im not 100% sure, but i believe it uses the TEMP folder for this kind of purpose.

The TEXTURE folder is where the Textures for the Particles are stored... and yes, its important that you set it correctly, otherwise the particles wont render with textures.... they will probably still render, but will be textureless and not look very good..

The Methods that are assigning those path's should be let alone, althoug you could possible setup your own temp folder there is no advatage in doing so, as you will need to manage it and add methods to make sure that it is emptied when the app exits..(its not needed, but is good practice to clean up any mess your program makes when its done running, temp files or folders mostly)

As for the render size, ill have a play with it when I get some time today and post back if it works or not... I imagine its because you are not changing all of the references to the image/render target being 512x512 (I think i listed them all but may have missed one, ill check) - so you can make it smaller, but not larger.

If it ain't broke.... DONT FIX IT !!!
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 3rd Sep 2009 18:10
Testing works continues on this side.
All seems to work fine.

However the only thing that is bothering me a lot is that because of this line:

dbSetAlphaMappingOn(6, 100);

the particles inherit a see through transparency all the way, not just the black border

hence they don't show as bright as they should, especially when there is a colourfull backdrop. Having the possibility to set the transparency is useful but I would like to get rid of the black border and have the actual particles without transparency.

I tried using the dbSetObjectTransparency() function with various values 0-6 but I still got semi transparent particles
Mista Wilson
15
Years of Service
User Offline
Joined: 27th Aug 2008
Location: Brisbane, Australia
Posted: 3rd Sep 2009 23:22
I'll hvae a look and see what I can do...

In the meantime you could try Ghosting the object with dbGhostObject and fading it, dbFadeObject, they might not work either, but that is another way to make transparency

If it ain't broke.... DONT FIX IT !!!
Mista Wilson
15
Years of Service
User Offline
Joined: 27th Aug 2008
Location: Brisbane, Australia
Posted: 4th Sep 2009 02:31
Ok, Ive had a bit of a look, and I cant quite see what you mean... Here are 2 screenshot closeups of the demo above...





You can see by looking(especially in the Matrix Text one) that the particles themselves do not contain any transparency, as that is how they were designed in the Magic Particles Editor.

The setup I used to take those screenies was to set the object's alpha mapping level to 100, and pass 0 for the particle's texture alpha level...

The only want to make them brighter and still keep the object transparency(they will look brighter with a solid non transparent object, but its an optical illusion I think) would be to send the same particle to the same texture multiple times, so its rendering itself 2 or more times to the same place, just not clearing the texture each of the extra times... Doing that would require you to modify the RenderParticles() function though to make it suit that requirement.

Otherwise, if you put it into an actual "game level" that is lit and ready to play, say a Fire Effect, you could place it in such a way the the lighting makes it look brighter aswell, you could also place it so that whatever is behind it, adds to the brightness.

The last thing I should mention, is that there will be some inherant drawbacks with this... it doesnt make the particles 3D at all, they are still compeltely 2D(until the MP guys finish their 3d version), all its doing is swapping render targets. You could still if you wanted, have multiple particles on the same texture at different places.. for example, you might have 2 different "fire" effects that you combine to make a "bonfire" or something.... you could send them both to the same texture. You could use multiple textured objects placed in a layer to achieve a pseudo 3d effect, but that would only work in certain places.

Hope this answers your question. If you still dont understand or if I misunderstood what you meant, feel free to ask some more, ill try to be clearer. Perhaps you could post a screenshot of what it looks like with your code(just the particles specific parts though lol) if its different from above.

Also, one thing to check before coding, is that the particles themselves werent designed to be transparent inside the MP Editor, if they were, there isnt alot we can do other than re-edit it to be non transparent.

If it ain't broke.... DONT FIX IT !!!
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 4th Sep 2009 14:23
I found what the problem was. In the Magic Particles editor, if you don't select INTENSE under the COLOR option, the particles turn up as semi transparent. I was very unlucky as this was especially apparent with the particular emmitter I was using! So basically it's a Magic Paticle "thing"
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 5th Sep 2009 10:26
Doing this helped too

dbSetObjectLight (6, 0);
Mista Wilson
15
Years of Service
User Offline
Joined: 27th Aug 2008
Location: Brisbane, Australia
Posted: 5th Sep 2009 10:54
cool.. I didnt alter how the object's were created by default very much at all besides applying an alphamapping level to them so they were essentially see though..

I guess sometimes you would want light and sometimes you would not.

If it ain't broke.... DONT FIX IT !!!
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 5th Sep 2009 13:54
the problem i was experiencing with light on is that the colours of the particles was showing too DULL and UNLIT. With the lights off command they were showing exactly like in the magic particles editor, which was what i wanted in this case.

however the system is very flexible now that i know that i have all possible options

Login to post a reply

Server time is: 2024-04-19 22:48:20
Your offset time is: 2024-04-19 22:48:20