Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 04 Jul 2011
Offline Last Active Yesterday, 04:36 AM

Posts I've Made

In Topic: How to import animations from commercial models (FBX, X) into Blender

23 June 2016 - 02:10 AM

Thanks for all replies. Turned out that there was some problem with FBX version probably, plus that file I bought was far from well organized. I upgraded Blender to 2.77 and used this tutorial:




and it finally worked, so I'm posting it, maybe it will help someone. Also had weird problem where everything imported but not the armature of a model, after long research and digging through FBX import addon (crazy code, thousands of lines) I managed to pin it down to a loose root bone that was encountered before the real armature root bone, and it caused only that one wrong armature to be imported to Blender. I skipped the bad one by dirty hack in addon code and suddenly the correct armature appeard. I filled bug and I'm waiting for some reply from addon's maintainer so hopefully this will be resolved for all cases.

In Topic: Sharing modules (but not globally)

17 January 2016 - 07:42 PM

GUI script may load more than one document, and if it gets unloaded at some point I think it wouldn't be necessary to unload that part of the script which came with unloaded document (but not sure yet, logically if document goes away so should the code that was contained in it). It's incremental loading that's the biggest problem, and your solution is probably the only one that will work. 



In Topic: RakNet still alive?

03 January 2016 - 05:07 AM


there is supposedly a ton of buffer overflow bugs


Don't believe everything you hear on the internet, unless there is verifiable evidence.
Can you link to one active bug report about a buffer overflow bug in RakNet (that shows a problem in the code)?

Second, if you need reliability over UDP, use Enet.
If you are using a particular game engine, like Unity or Unreal, then look at the default solutions for those engines.



Hence "supposedly" smile.png I just got that impression by looking at issues on github, and haven't really checked&confirmed any of those (I just need library that works, if I were to spend time checking for these things in every thing I use I would never get past main() in my project):








Some are not very detailed, but one can get the impression there are more such bugs than should be in mature library. Saying this, I'm still hoping RakNet is stable enough to be used in my project, I already integrated it and it worked in development settings for these years, but these signs (selling RakNet, new owner just letting it go on GitHub where noone even approves PR) made me a little worried. Every time I upgraded to new RakNet version in the past I struggled with issues like errors/warnings, problems with CMake generation, so every time it left a feeling that lib may not be as polished as other 3rd party things i use.


I considered Enet but at the time I made the decision it was slightly too low-level for my present knowledge and what I needed - reliable UDP client-server architecture, but also some helper methods for packing data specific to games (vectors, quaternions), so some nice way to read/write data into packets (like RakNet's BitStream), way to prioritize packets, channels etc. This means that right now I'm probably using 5% of what RakNet has to offer, and probably won't be using much more - I will handle object sync myself, not using some ReplicaMaster, same for chats and all other in-game activity. I may need some secure crypted data connection for logging too (I think RakNet also has it).


I'm staring to wonder what would be better in such case:


1) staying with RakNet, as it works, even if I'm using just a small percent of functionality and there are previously mentioned issues with the current state of project

2) trying to convert to some lower level lib like Enet, and adding needed functionality that I'd lack compared to RakNet (plus making it more in object oriented manner). Are there any libraries based on Enet that are slightly more high-level, but not as big as RakNet?

In Topic: RakNet still alive?

02 January 2016 - 04:00 AM

RakNet is one of the most mature pieces of middleware around. I wouldn't be that worried that the pace of development has slowed.


Besides, Unity uses RakNet, so on that alone, I doubt it is going to die off anytime soon - if there's any danger of it, someone will fork the codebase.


Sorry for resurrecting this thread, but recently I had to rebuild my project from scratch and found out RakNet is no longer "alive". I'm not sure how this is possible. I've been using RakNet for 3 years now, and to be honest it always seemed like really messy framework (but it worked so far with my limited needs). Build files are terrible and always require some hand-tweaking, and there is supposedly a ton of buffer overflow bugs and few other major problems. Source has been abandoned by OculusVR and only some life can be found in forks, which have their own problems and don't compile out of the box on popular compilers like MSVC2015. 


How library that has been around for so many years can end like this? Are there really no alternatives? Should I stick to RakNet since I already use it in my project and try to somehow fix the problems and follow some pull requests from the community, or there is some reasonable alternative (in terms of functionality, I need some UDP network layer with reliability options for client-server architecture). 

In Topic: Best practices for packing multiple objects into buffers

17 February 2015 - 08:44 AM

Since my previous post went unanswered I will try once more, maybe stating what my problem is in a more clear way.



That said, IMHO handling terrain chunks and batching meshes of multiple objects are two distinct use cases. They are so distinct that both require their own solution. I would generate a single vertex buffer for terrain, replacing regions of content when necessary. Why? Because rendering terrain will happen also in situations where more than a single chunk is visible at a time. If you would use multiple buffer objects, then you would switch buffers even during a single rendering pass of terrain. Using multiple memory blocks would mean to duplicate chunks in GPU memory. On the other hand buffer memory management would be relatively easy, assuming that the memory footprint of chunks is fix.



What about terrain chunks whose size is not fixed? I have modifiable terrain (mesh is extracted from 3D binary volume) so size may differ greatly based on how fragmented the terrain is - it can be flat hill with lowest amount of vertices, but also can be totally rough and fractured with much bigger mesh surface and thus vertices amount. So far I used single VBO per chunk, but I plan on having really big draw distance and it starts to hurt especially that chunks go in 3 dimensions and there can be several hundreds of highest LOD chunks (of course more LOD levels and concatenating chunks into bigger ones will also be implemented but still I think there is a lot of VAO switching that could be avoided).


I'm trying to figure out some custom allocator that would manage a single VBO (or few big ones, depending on total size of terrain geometry), but I can't figure out how to modify chunks that were changed, and also stream new chunks in/out as player moves. With a buffer of fixed size with N slots it would be easy - just swap old chunk with new chunk (whether new one is because player moved or digged existing chunk, doesn't matter), but I can't figure it out for dynamic chunks.


My initial idea was to allocate slightly more than needed - check what's the max size of chunk that exists now, allocate maybe 1.5x as much so all chunks will be padded and this will allow for them to grow or shrink without affecting other chunks in the memory. Problems start if there is situation where chunks grow beyond fixed size - what to do then? It also wastes a bit of memory of course, but not sure if that would be any significant amount. 


Another idea would be to not pad to fixed size, but just allocate big enough buffer and put chunks one by one in linear way. If chunk that already exists changes it's geometry, I check if it's the same size or smaller - if so I just overwrite that chunk data. This will leave some portion of buffer orphaned, and it will probably be so small chunk of memory that it will be wasted forever. This can lead to buffer fragmentation at some point and also requires some fancy allocator that will keep track of memory use and find a place for new chunk to occupy if it exceeds it's current location space.