Scott Richmond

The difference, mate, is that its in one easily accessible and viewable list. Let me put this to you - When people come to the programming forums and ask a question or go looking for an answer wouldn't you agree that for the majority of the time the answer won't be in pure code? And for times when it is in pure code, it'd most likely be LE code that could easily be understood in any of the available languages. So why purposefully segment up the community? Doing so simply increases the chance of someone asking the same question and getting the same answer in each of the separate sub-forums because we all know search is one of the least used features in any forum. No one does it on purpose. Its simply because the post is in another list - Most people won't manually scroll through several pages of threads for the same reason they won't go visiting different sub-forums - Its too much effort - You'd be better off running a search right? Honestly I don't believe this is that big of an issue. But I've always subscribed to the idea of an easily searchable flat file/list/document structure in any system - Its best at avoiding duplication of data and is efficient. By the way - I completely agree regarding the programming tutorials / articles / documentation. Its all hidden under these menus under sub-menus within pages indexes. Its crazy. Its all made worse by the fact that the search functionality is actually really quite bad. Why can't I just search in every area of the website instead of picking specific types? This website is nice looking and all, but some of the core functionality is really out of whack.

Except with that method you have completely separete programming communities, each having their own isolated base of LE knowledge. Its a grand waste. Joining them all together allows all programmers to help each other out and provide much larger base of knowledge on LE.

Josh, I completely agree. Cutting the programming forum up like it is now creates duplication of common questions and problems with a LeadWerks engine, which are majority type of thread posted. As has been said previously the LeadWerks code is fairly well cross-language and even more so in LE3 I'm sure, so I don't believe there is much reason to keep things the way they are now. One way to ease the pain of transition could be to enrich the posting interface to have code tag buttons for C++, C#, BMX, LUA on the WYSIWYG editor. This will allow people to more easily spot the type of code they're looking at. Something else to consider might be to add an 'Off Topic General Programming' sub-board under Community to allow people to post programming based threads that have nothing to do with Leadwerks. For example "How does C++ work and can someone make it for me?" PS - The main 'Leadwerks3D' and 'Leadwerks Engine' boards are a huge cause of confusion for me too by the way. I always click the top programming section by accident and wonder for a second where all the posts have gone. I world imagine it would be much more difficult for someone new to understand it.

Hi guys, I've spent the last day reading up on and learning Qt as well as searching high and low for any C++ examples of anyone using custom buffers to render to another OpenGL context and have come up with nothing. Apparently someone had got it working previously but it must have been lost in the last forum purge. I'd love it if anyone could pipe up if they've worked it out. This is what I've got so far: Extremely old C# example of how to use custom buffers to render to a Windows form GL context. Forum post circa 2009 discussing the c# custom buffers and having problems. Leadwerks Wiki entry on CustomBuffer. Has no examples. Looks like a .NET attempt at custom buffers. Finally, very easy to understand Qt guide on a simple OpenGL Hello World application for those interested in helping me integrate Leadwerks.

Nice. Its a pity its not in C++, as I cannot use it.

Hi, I need to be able to completely remove a model instance from a running LE game during runtime via C++. Any ideas? I've tried .free() and it seems to do nothing. I've tried deleting the pointer object, but I don't think Model has a comprehensive destructor setup. Help?

An updates on this mate?

I have to agree with Metatron - Whilst it was a good news story in the end, thats a pretty bad way of troubleshooting and recovering from the issue. I would be worried as to why the backup wasn't made before the cPanel upgrade - Everyone knows you do a backup before any update or upgrade.

Metatron - Please do. I think there are valid cases where the default OC in LE2 isn't very efficient. Where as a simple manual system as Game Producer describes would be better.

Careful with the painting part of it - If you plan to merge entire regions of terrain into a single mesh then you'll only have a set number of textures to play with.

Oh interesting. I did not know that.

I think you mean C++0x. But you're correct. Its why I mentioned the TinyThread library, as its an implemented of C++0x.

Agreed. I managed to get simple procedural terrain meshes going in LE2 relatively quickly previously. Theoretically you could implement some sort of cell framework like Oblivion did and have endless procedural terrain.

ZMQ is really a communication pipeline that allows you to sidetrack the whole process of trying to interlock and all that other nasty thread stuff by just implementing fast message passing. Its really good if you're willing to design using their concepts. For pure threading, I might also just point you to TinyThread: http://sourceforge.net/projects/tinythread/ Kind of sounds like the wrapper class you're making now.

Don't know if this is any help to anyone but I thought I'd just say that if one needs some sort of reliable, safe and easy inter-thread communication then ZeroMQ is an amazing library.

You're assuming we're using a scene file. For the project that pertains to this issue, I'm procedurally generating terrains during runtime. The 'map' is made up of a huge amount of models. The polygon count isn't the problem, its the occlusion culling that causes the problem as more and more models are introduced as the player traverses the map. I've managed to optimize the OC octree by tweaking the CLOSE, NEAR, FAR (or whatever they are) groups ranges on the camera which seems to do ok, but I think more could be done. The code in this thread above plays with that. I'm wondering out loud here - Would parenting groups of models help? Does OC ignore parent-child relationships or does it only check the parent model? How does the vegetation rendering work?

Ah I see. That's really unfortunate as it would work well in this specific use case. Looks like hide and unhide might work best. Unless we can make use of the vegetation system somehow.

Josh - vegetation system? I would like to hear more about that if you would. I'm guessing its a shader? can I also confirm that you meant cull groups are unsupported? Kazaar - your cull group code isn't helping because you need to put your tiles into multiple large groups, not just one. Assuming its supported.

I haven't tried this yet but you'll probably need to .hide() all models by default, and .unhide() models that are within the camera frustum. The .hide() method takes the model right out of the OC detection so massively reduces the OC time. But it'll need to be done cheaply. Like if the 'tiles' are a 3D matrix then it should be cheap to know that when the camera moves from (1,1,1) in the world to (1,1,2) then you need to .unhide() all the models at (x,1,32). Not sure if that makes sense to you or not - I'm avoiding the problem for now and working on stuff not specific to the engine. I might have to find a new engine for this project unfortunately. Ah that too! I must say I haven't tried groups yet. That would probably be the best way.

I recently went through the same process. Read through my thread here: http://www.leadwerks.com/werkspace/topic/3956-model-setviewrange-causes-crash/page__p__35154#entry35154 It starts off unrelated but gets on to answering your questions.

So, the engine can run under wine but not native Linux? And to compile under Linux we need MinGW?

Any documentation or examples? Can one just use the example code and compile? Can it be compiled under linux, or does it just RUN under linux?

Hey, I've got a friend who'd like to join me in a simple game project and he simply refuses to use Windows being a hardcore Linux fanboy. So, I come here asking - Does the latest LE2 engine run under linux? Anyone does so? Any complications, etc?

the code should compile on whatever system you choose providing you include LEO. I can send you a vc2010 project if you like.

Have you tried it in the above demo? It doesn't make much if any difference.