Ohhh, so this is what you guys have been working on in the Instancing thread. Very cool. Any chance you're going to be putting that script in the store, or possibly upload as a resource? ~she asks hopefully~
-
Welcome to the Community Forums at HiveWire 3D! Please note that the user name you choose for our forum will be displayed to the public. Our store was closed as January 4, 2021. You can find HiveWire 3D and Lisa's Botanicals products, as well as many of our Contributing Artists, at Renderosity. This thread lists where many are now selling their products. Renderosity is generously putting products which were purchased at HiveWire 3D and are now sold at their store into customer accounts by gifting them. This is not an overnight process so please be patient, if you have already emailed them about this. If you have NOT emailed them, please see the 2nd post in this thread for instructions on what you need to do
Show Us Your Dawn Renders!
- Thread starter HiveWire3D
- Start date
-
- Tags
- dawn dawn special edition
Hehe this was NOT what that thread was about, but I posted there because it was directly related to it. Scattering wouldn't be possible if Poser didn't support instancing, because it would quickly lead to running Poser out of memory. We did many tests to see how adding things to the scene affects memory load, like loading a raw OBJ against loading a linked geometry. Rumor claims that linked OBJs benefit from instancing, while embedded geometries won't.
As for the scattering script, I have just started writing the code a couple of days ago, and was glad to see results so quickly. I am now building a graphical interface for it using Tkinter, which I am not very familiar with. I usually prefer PyQT, which [I believe] is not supported in Poser, so I have to learn Tkinter first. Shouldn't take long.
I also want to add support for scatteting over morphed surfaces, but I will look into that once I have a GUI I can use directly from Poser. ^^
fun with texturing things great outfit
Attachments
-
Avenger3-RN.jpg
Hornet3d
Wise
WOW, I like a lot
Now if that doesn't look like a great promo render Dan, I don't know what does.
Love it! ^______^
I have just replaced TKinter with the more modern WX widgets, so now the tool has better performance, and the buttons no longer glitch when clicked. After this experience, I am definitely not using TKinter anymore. WX looks nicer, and we can dock the tool into Poser as if it were part of it. So far things work great, but I still don't know how to close a WX app with the Exit button. The "X" button from the title bar works, but my button doesn't. Instead of closing the tool, it crashes Poser.
I have reworked the whole WX interface trying to solve this, but the utter lack of documentation is not helping. There is a lot of guesswork. It's funny that all the code works fine, but I can't make the Exit button work in Poser. It works in stand alone WX apps, but not in Poser. I hope I can figure this out soon.
I'm familiar with TKinter, as it's been around for quite a while. I've not heard of WX widgets before. Surprising there's not documentation. I would think any kind of software would have documents to help new users.
Edited to Add: OK, I went to the download site, and clicked on a link for the ReadMe, and it had a link to online Documentation. You might want to check it out --> WX Widgets Documentation
Edited to Add: OK, I went to the download site, and clicked on a link for the ReadMe, and it had a link to online Documentation. You might want to check it out --> WX Widgets Documentation
Yes, one would think that would be useful, but it doesn't cover wxPython nor Poser, which work in different ways than the default. The documentation you have linked to is for C++, while Poser uses the wxPython version. I can close the app when running stand alone code outside Poser, but not from inside. That's because Poser uses the WX widgets natively on its interface, so the top level frame and the main loop already exist even before you write your first line of code. We cannot create any of those - we have to use the existing ones from Poser. The online documentation won't cover any of that, so we are left in the limbo. When coding WX GUIs in Poser, we are extending the existing one, so we never build it from scratch, which is how things are "normally" done and explained in online documentations.
These sites will tell you to close a WX window with "self.Destroy()", which in my experience will simply crash Poser back to the desktop. That's probably because we are trying to destroy Poser's own interface instead of our app. Conversely, a simple call to "self.Close()" closes a WX app when in stand alone mode. From Poser, that simply has no effect.
Everything else works wonderfully. I just couldn't figure this part out yet.
Last edited:
I have found WX quite familiar from the very beginning because it looks like QT in the way the classes were designed. I have used QT in my Python programs for a while and have become proficient with it, so WX was quick to pick from there. The thing here is that the Poser interface was made with WX, so there should be a special way to close our external apps so that we don't actually kill the Poser interface along with it. This is particular to wxPython and the way Poser uses it, so I believe all online documentation will be useless for this point in particular.