New Update v1.22
Home › Forums › TimelineFX Editor › New Update v1.22
- This topic has 13 replies, 2 voices, and was last updated 14 years, 1 month ago by imported_peterigz.
-
AuthorPosts
-
August 8, 2010 at 11:32 am #3178
imported_peterigzParticipantJust a few bug fixes for this update, mainly for intel GFX users. Here’s the list:
* Improved compatability on the range of mobile intel GMA cards/integrated – Thanks to vgreano and NielsJL for testing!
* Fixed a bug with single frames not exporting properly
* Exported animations now have the black background removed properly.
* Clipboard is cleared when opening a new effect library, as pasting was causing errors. Use import library to bring in effects from other lirbraries.Available from the download page: http://www.rigzsoft.co.uk/index.php?option=com_content&view=article&id=6&Itemid=19
August 27, 2010 at 4:36 am #3691
vgreanoParticipantHey, thanks for the update. One minor issue…
SO I installed the new version, and there’s a color problem with the export. I set up some smoke (Taken from Explosions – Fireball Explosion Quick Area I believe) and when I exported the frames, I got more black around the edges for a white background. I attached an image of what is going on, its strange because it only happens on that specific emmiter.
Also, is there a way to customize the size of the export grid? I would like to have it 6xheight
August 27, 2010 at 9:30 am #3692
imported_peterigzParticipantRight, I can see what’s happening. If you look at the Fire particle in that effect you’ll see that it goes from orange to black, but the alpha doesn’t fade out until right at the end of it’s life. So what’s happening is, although the renderer doesn’t render a black particle if it’s using additive blend, the export still sees those black pixels because the alpha isn’t zero. I’ll have to adjust the exporter to take that into account.
Meanwhile you should be able to fix it by setting the alpha to zero at the same time the particle becomes black, or it might work better if the particle stays orange and just fade the alpha earlier. Just when I think I’ve sorted the exporter something else crops up lol. Thanks for the report 🙂
August 27, 2010 at 11:00 pm #3693
imported_peterigzParticipantSorry, I didn’t answer the other question. You can’t customise the number of rows/columns no. the main reason is, that it keeps the texture sizes in powers of 2 as is what’s required of most graphics cards.
As for the issues with black, additive blended particles, what a headache! Haven’t really got very very far with that yet, but will keep at it and let you know. But meanwhile like I said, you can just avoid the dark additive particles and it should be fine.
August 28, 2010 at 6:10 am #3694
vgreanoParticipantOh okay, I realized if I keep the export rate to 36, it should stay within my specifications. I’m importing spritesheets into flash and blitting them so, thats why I was asking.
Anyways, I tried out your suggestions, and it made sense what you said, about keeping the orange consistent, but it still puts the black glow border. It’s smaller than what it was before, but why would there be a black glow? I even tried setting the alpha (Alpha Overtime I assumed) to 0 a lot earlier, but no go it seems.
Anyways thanks for looking into this, hopefully its not too nerve-wracking.
August 29, 2010 at 12:51 am #3695
imported_peterigzParticipantI think I’m almost there with this. I think really there wasn’t much of a problem, although I am going to make a change that forces particles to be loaded as greyscale if they don’t speficy that they should. That effects file was created before I had implemented importing shapes as greyscale, so it has greyscale images being imported as full colour, this has a subtle but noticeable effect on the export.
Having changed that the big black blob on the export has gone, however the black halo is still there – but – that is more or less correct. The smoke particle on that effect is pure black, and all exports are rendered on a black background, so it is rendered as black, despite the black background being removed. Even though it’s removed, the particle is still black so it doesn’t make much difference. To compare the exported animation against the editor on a white background will always look different because if the editor renders black on white with a bit of transparency then it will come out light grey. It has to render on black otherwise all additive particles will always come out white.
So where does that leave us? lol. Well I’ll make that update tomorrow that sets greyscale as default, although I want to test some more first in case it messes something up. But as for correcting the effect with the black, simply making the black smoke particle a lighter grey should do the trick i think.
[attachment=0:3n3d5lvf]explosion.png[/attachment:3n3d5lvf]
August 29, 2010 at 6:34 pm #3697
vgreanoParticipantYeah I seem to get a thin, but noticeable black border around my elements after applying your suggestions. Looks strange when particles start to scatter and get smaller. Your export looks like its more or less solved the problem however, but I was thinking…for the Color Overtime, would it solve the problem if you added the option to select transparency as a color, ie: orange to checkered? Or is it possible to create a good fire effect without using the Additive option?
Anyways, looking forward to your update!
August 29, 2010 at 6:55 pm #3698
imported_peterigzParticipantThat’s essentially what the alpha overtime is doing. If your target background is white or very light, then avoiding black in your particle colours makes sense I think. So if you just adjust the smoke particle to use a light grey it should look a lot better.
August 29, 2010 at 11:48 pm #3700
vgreanoParticipantSo I tried exporting the animation by completely removing the black smoke, but the black outline is still fairly prominent. After this, I was doing some random testing with this, and I found that removing the additive property shows the shape in its true form. It looks like the shapes I was using (fire1.png and smoke1.png) both originally have black borders around them, so they cannot be removed regardless. Could this be it, with the source PNG having a black border around it?
August 30, 2010 at 12:19 am #3701
imported_peterigzParticipanthmm could be. Can you import that effect into a new effect file and attach it here so I can take a closer look?
August 30, 2010 at 12:44 am #3702
vgreanoParticipantSure thing. I posted the exported file as well as the effects file. Notice how different they look!!
Here’s the dropbox link — its 4MB, I couldn’t attach it here.
http://dl.dropbox.com/u/486220/snowfare_test.eff
Thanks buddy
August 30, 2010 at 1:19 am #3703
imported_peterigzParticipantI think I’ve got the simplest solution to this, should have just done it in the first place lol. I changed it so that if you change the background to white (in the animation properties window), then it will export with the white background and not bother trying to remove the black (obviously it’s not there to remove). I think for what you’re trying to do it should work fine, in other situations additive particles would probably saturate too much.
Give it a go, same d/l link: http://www.rigzsoft.co.uk/files/TimelineFXEditorSetup.exe
All black should be eliminated now, but make sure you export with the white background. BTW, I noticed you had seamless option ticked, that’s only necessary for creating textures that you want to tile seamlessly. If it’s checked then you can’t use the autofit function which will make sure you’re making the most of the space in the frame.
August 30, 2010 at 1:52 pm #3704
vgreanoParticipantYou RULE dude! It works great, I guess it was a simple fix after all. Thanks for the seamless tip as well, I wasn’t sure what that did.
August 30, 2010 at 10:53 pm #3705
imported_peterigzParticipantGreat, glad to see it work 🙂
-
AuthorPosts
You must be logged in to reply to this topic.