Particle Preview

[greebo]

I've started to work on an improved particle selector, with a preview. The particle renderer is about 50% done, so I'm able to show a bit of progress now:

 

 

Once the renderer is done, there is nothing stopping us from writing an improved Particle Editor plugin. But this is kind of boring work, so don't hold your breath about that one.

[OrbWeaver]

Awesome. The particle renderer is the "cool thing" I always thought would be fun to implement, but imagined would be too difficult because of renderer limitations. I guess you've solved at least one major problem with the RenderSystemFactory however, enabling the use of multiple renderer instances instead of the one singleton instance.

 

I have some WIP changes to implement the use of GtkBuilder/Glade for interface design, so maybe this will be motivation to actually use it for an actual new GUI.

 

How does the animation work (if any)? Is it thread based, or GTK idle-callback based?

[greebo]

How does the animation work (if any)? Is it thread based, or GTK idle-callback based?

It's really basic, nothing spectacular. I just added a gtkutil::Timer (based on gtk_timeout_add). It is attempting to refresh the view every 16 msecs. If that doesn't work due to the previous render being still in progress, the refresh is delayed by another 16 msec. No explicit threading, I don't know how GTK is handling it internally.

 

(You can have a look at it yourself in the particles branch, if you like, most particles are already half-way working.)

 

Btw, I've been holding back from merging your recent trunk changes, because I'm missing two source files - could you check them in?

[Sotha]

Excellent!

 

No more catalogue maps with zillions func_emitters to shop for particles!

 

Thanks!

[OrbWeaver]

It's really basic, nothing spectacular. I just added a gtkutil::Timer (based on gtk_timeout_add). It is attempting to refresh the view every 16 msecs. If that doesn't work due to the previous render being still in progress, the refresh is delayed by another 16 msec. No explicit threading, I don't know how GTK is handling it internally.

 

Ah yes, that's what I meant -- GTK timeout not idle callback. That's how I was thinking to do it, since a perfect framerate is not critical anyway.

 

Btw, I've been holding back from merging your recent trunk changes, because I'm missing two source files - could you check them in?

 

Damn, I didn't realise, sorry. I'll check when I get back home (any missing files will be on my home PC).

[New Horizon]

Looking good greebo. I wasn't expecting that at all.

[grayman]

Loverly!

[SneaksieDave]

Wow! Yeah I'd say with a rendered chooser and "flush and reload particles" or something like that, an editor is just icing on the cake (iow, not vital). Very very nice.

[Baddcog]

looks very cool.

 

to be clear though this is just a viewer right, not an editor? - still have to go to console to edit/create.

[Springheel]

This is awesome! Thanks greebo!

[greebo]

Thanks, guys.

 

to be clear though this is just a viewer right, not an editor? - still have to go to console to edit/create.

Yes, this is the viewing part I'm coding on, but it's the much more difficult part. The editor is GUI work, which is not hard, just tedious.

[Tels]

Cool stuff, this is really useful for Linux users (who can't use the in-game particle editor).

[greebo]

More progress: after implementing the "view" orientation type, almost all D3 particles can be properly played back now (including the ones with "animationFrames", "aspect", "fade fraction" and other funky stuff).

 

What's left to do:

 

- Add support for the orientation "aimed" which is a bit harder than the rest, requires some more reverse-engineering.

- Add some more preview controls to restart and stop playback.

- Tweak default direction.

 

After this will have been done, I'll merge back into trunk.

[Baddcog]

Sounds great.

[New Horizon]

Nice! Sounds great Greebo. This will be a lovely addition.

[demagogue]

Great!

 

Just so you know, since you mentioned how tedious it would be to make a particle editor, it's worth saying how terrific it would be for mappers. I remember looking for a drip particle and the only one there wasn't very good, and I had a sinking feeling not knowing at all how to make the particle I wanted (one thing I really missed from dromed). We all know how particles, used well, can really add magic & immersion to a map. So working on an editor plugin is Good Work. I understand setting priorities and all; I just didn't want you to get sucked into the tedium without a little more encouragement about how nice it would be and that it's worth it.

[Tels]

Great work as always, greebo! Looking forward to the preview, that should be much faster for Linux user instead of having to load a map in D3.

[greebo]

Finally, the preview is feature complete. The last 10% were the hardest, as expected, but I'm through now and DarkRadiant's preview offers support for all the particle features in Doom 3. The toughest feature was the "aimed" orientation which was pretty hard to reverse-engineer, followed by the animationFrame fading. Very tough, but a fun and challenging project in retrospect.

 

The stuff is going to be merged back into the trunk, so I hope there are not many linux compilation issues, but if there are any, could you please take care of them, OrbWeaver?

 

Some screenies:

 

A helix particle using aimed trails with large time values and inverse gravity

 

The particle I used to reverse-engineer the custom path "flies"

 

D3 torso_fire particle

 

Soul particle with aimed trails

 

TDM Fire particle:

[Fidcal]

Amazing - look forward to this. Should encourage more use of particles too. Are particles preloaded? I'm just wondering if I edit a particle def can I then view the change in here? Or does it need a 'reload particles' feature in the file menu?

[greebo]

That feature is already implemented. The "refresh" button you see in the screenshots is connected to "Reload Particles".

[OrbWeaver]

The stuff is going to be merged back into the trunk, so I hope there are not many linux compilation issues, but if there are any, could you please take care of them, OrbWeaver?

 

Yep, no problem. Hopefully I will also find some time to flesh out the GtkBuilder implementation so that designing an editor GUI is easier.

[greebo]

Thanks. My changes are in the trunk now. Hopefully it's not too much work getting it to work.

[New Horizon]

Looking spiffy.

 

Put your feet up and take a well deserved rest.

[greebo]

@OrbWeaver: I installed Ubuntu 10.10 and my compilation is failing on the gtkutil library with this message:

 

libtool: link: g++ -shared -nostdlib /usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../../lib/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.4.5/crtbeginS.o .libs/ConsoleView.o .libs/GLWidget.o .libs/PanedPosition.o .libs/VFSTreePopulator.o .libs/Timer.o .libs/WindowPosition.o .libs/PersistentTransientWindow.o .libs/Dialog.o .libs/MessageBox.o .libs/dialog_legacy.o .libs/glfont.o .libs/MenuItemAccelerator.o .libs/cursor.o .libs/DeferredAdjustment.o .libs/PopupMenu.o .libs/widget.o .libs/RegistryConnector.o .libs/PathEntry.o .libs/TreeModel.o .libs/ModalProgressDialog.o .libs/SerialisableWidgets.o .libs/SourceView.o .libs/clipboard.o .libs/FileChooser.o -Wl,-rpath -Wl,/home/greebo/darkradiant/libs/xmlutil/.libs -Wl,-rpath -Wl,/home/greebo/darkradiant-install/lib/darkradiant /usr/lib/libgtkglextmm-x11-1.2.so /usr/lib/libgdkglextmm-x11-1.2.so /usr/lib/libgtkglext-x11-1.0.so /usr/lib/libgdkglext-x11-1.0.so -lGLU -lGL -lXmu -lXt -lSM -lICE /usr/lib/libpangox-1.0.so -lX11 /usr/lib/libxml2.so -lgtksourceviewmm-2.0 -lgtksourceview-2.0 /usr/lib/libgtkmm-2.4.so /usr/lib/libatkmm-1.6.so /usr/lib/libgdkmm-2.4.so /usr/lib/libgiomm-2.4.so /usr/lib/libpangomm-1.4.so /usr/lib/libgtk-x11-2.0.so /usr/lib/libglibmm-2.4.so /usr/lib/libcairomm-1.0.so /usr/lib/libsigc-2.0.so /usr/lib/libgdk-x11-2.0.so /usr/lib/libatk-1.0.so /usr/lib/libgio-2.0.so /usr/lib/libpangoft2-1.0.so /usr/lib/libpangocairo-1.0.so -lgdk_pixbuf-2.0 /usr/lib/libcairo.so -lpng12 /usr/lib/libpango-1.0.so /usr/lib/libfreetype.so -lfontconfig /usr/lib/libgobject-2.0.so /usr/lib/libgmodule-2.0.so /usr/lib/libgthread-2.0.so -lrt /usr/lib/libglib-2.0.so ../../libs/xmlutil/.libs/libxmlutil.so -L/usr/lib/gcc/x86_64-linux-gnu/4.4.5 -L/usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../.. -L/usr/lib/x86_64-linux-gnu -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/x86_64-linux-gnu/4.4.5/crtendS.o /usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../../lib/crtn.o -Wl,--export-dynamic -pthread -pthread -pthread -Wl,-z -Wl,defs -pthread -Wl,-soname -Wl,libgtkutil-1.5.0.so -o .libs/libgtkutil-1.5.0.so

libtool: link: (cd ".libs" && rm -f "libgtkutil.so" && ln -s "libgtkutil-1.5.0.so" "libgtkutil.so")

/bin/sed: can't read /usr/lib/libgdk_pixbuf-2.0.la: No such file or directory

libtool: link: `/usr/lib/libgdk_pixbuf-2.0.la' is not a valid libtool archive

make[3]: *** [libgtkutil.la] Error 1

 

It is a bit different to the message posted on the bugtracker, but it's the same library causing troubles.

[OrbWeaver]

That's actually a bug in the libgdk-pixbuf-2.0-dev package in Ubuntu 10.10. I just submitted a patch that allows you to build a correct version of the package to Launchpad:

 

https://bugs.launchpad.net/ubuntu/+source/gdk-pixbuf/+bug/665768

 

Other than that, I've updated the DR Linux build scripts and everything looks fine, including the particle previewer.