The BGE team (active on UPBGE branch) is motivated to make sure BGE will use new viewport and
gets the necessary updates to keep work in 2.8.
- Best would be if we can get the BGE team work with Blend4web and others to redesign the logic system.
UPBGE team is interested. Let's have this discussion (by contributors) on bf-gamedev list.
full mail -
Hi everyone,
Here are notes from today’s 14 UTC meeting in irc.freenode.net#blendercoders.
Blender 2.78 release
Some last regressions were reported and fixed. But we’re ready to call for the release monday.
Bastien Montagne will come with new doc about assets, data blocks, linking, etc.
Blender Institute workshop about viewport was a blast! Mike Erwin, Clement Foucault,
Dalai Felinto, Sergey Sharybin and Ton Roosendaal participated. (Lubos Lenco had to cancel).
Mike and Dalai will come with a report, design and planning proposal soon.
Ton will come with a general plan/proposal for the 2.8 project. In short:
Put all efforts on viewport (realtime PBR, realtime compo, new layers, etc), on workflow and
UI updates, assets/linking/overrides, finish depsgraph, clean up modifiers/derivedmesh (node ready),
but postpone the ‘everything node’ and hair/particles nodes.
The BGE team (active on UPBGE branch) is motivated to make sure BGE will use new viewport and
gets the necessary updates to keep work in 2.8.
Best would be if we can get the BGE team work with Blend4web and others to redesign the logic system.
UPBGE team is interested. Let’s have this discussion (by contributors) on bf-gamedev list.
That’s great that the UPBGE team and the BF are interested in working together, but is it too late to really make it into an engine that can stand on its own as a serious development platform (compared to Unreal, Unity, and Godot)?
Perhaps if that all panned out, I can actually finished the projects I have started years ago in the engine (because I would no longer have to deal with random breakages in each release). The biggest weakness of the engine then would shift to the fact that it is GPL, and I’m not sure if it’s possible to deal with that without complicating the process of game publishing.
UPBGE is intended to be the BGE, but with the codebase actually cleaned up and modernized (which they somehow managed to find the dedication and time to do).
I’m glad to hear that. As someone interested in BGE I’m looking forward to UPBGE, but for the mean time I’ll see what I can learn in BGE. UPBGE might not be able to compete with top tier engines like Unity 5, UE4 or Cry Engine 3 but it might just be the best thing for iOS devices.
Will I finally be able to align text, let alone use the full feature set of text boxes? Will controller-hotplugging be supported? Will I be able to control Character Physics enough to stop constant sliding down even the most miniscule slopes?
Graphics be damned, and to hell with mobile; when will I have basic fundamental functionality?
Heh, yeah; lordloki76’s hotplug patch should be in next week or so: I’ll happily concede that.
Beyond that, everything you offered are workarounds we shouldn’t need. Why can’t I just use the buttons that are plainly available in the editor to do what the buttons say they do? Why are some physics objects just written off as being broken and useless without question?
I’m very much a fan of Blender, and even I can’t stand these hindrances. The poor market share of the BGE shows how little the population at large is willing to put up with not being able to do basic things.
I agree that BGE has a future, but its not the same future you see. I see the BGE becoming a Blender Intergrated Game Development Environment or BIGDE. Maybe even call it the BIG Development Environment.
Not quite sure were I am with the Blender Game Engine now. I make maritime basic routes which also include miles of docks and working locks. I just removed the 50 km routes I made from my site as they would not load or started loading very slowly for some reason. I am going back to making the 20 km routes following around the UK starting from Solway Firth. 26 routes made and up to Barmouth. Have 3 available for download including Liverpool 1800 and 1837 based on srtm2 data available from my site see link at side of my posts to ny site. one and half and 3 miles of docks inluding Liverpool’s very first brick built dock.
Also currently have the river Alt route and Mersey Estuary which I made half tidal available for download.
The point is having made these routes over a few years BGE seems to have most of the functions needed to make maritime routes but seems ‘neglected’ with the emphasis on small games. With little to no feed back and discussion re simulations so on my own. Incidentally there was no apparent function in Blender to make boats ‘floating’ suitable to include in my downloadable routes so devised a simple method of offset collision box with base of collisionbox at waterline. Changing to rigid body from dynamic made the boats usable in the working barge locks and through the narrow dock entances to dock gates. Before they vibrated violently and climbed out if bow and stern touched opposite walls at the same time. These things take me months to try and find what will work suitable to adapt for maritime.
As far as I know I do not know of anybody who makes maritime simulation with it. So perhaps the working simulations should have a more prominent position at least on par with small games.
I will make the downloads back up to 10 routes or so, maritime basic of around two centuries ago at 20 km. A great amount of effects and scenarios can be created including the world of canals, ships, docks, shipwrecks, ship launchings, steamships, paddlers, etc, of any country in the world…if there was an increase in interest. There are open source Aviation and Railway simulations and I think the same might be possible for maritime WORLD with the BGE. A Long post but I think important. Maritime routes don’t have to be complex, such a online racing, complex navigation, etc, as they can use quite basic functions as shown in my working barge locks at Ellesmere port.
I hope the people who are going to work on this knows how to improve upon the logic bricks. I’m not very impressed by fancy graphics, a game can still be great even with ps3 or ps2 graphics. As someone else said, the fundementals need to be improved upon if anyone is going to put up with making games in the bge. Easier management of assets, better control of the game camera, slow parenting a camera to a character isn’t always enough.
I have commented on this in another thread but the AND thing between every single logic brick command don’t make sense. Allow the logic bricks to go on forever.
your Maritime game needs terrain to be loaded in and out as you move,
should fix your framerate issues.
break the terrain up into small pieces and use a tree structure to load chunks in and out.
with BPplayer apparently we can pack game data that has already been converted from blender data, meaning it does not need to be converted when loaded unlike libload,
Thanks for info. My knowledge is limited although enough to make working locks, miles of docks etc, and AI boats. I would need descriptions and detail of how to create the effects mentioned also they would need to have been tested in 20 km size routes and be a permanent feature workable in the future. I am unable to follow complex video tutorials on my computer. All I can do is make the routes available in the downloads, and perhaps maritime feedback and discussion ‘might’ increase ‘hopefully’. I think it is more about others becoming interested in the variety of ‘possibilities’ that might be available. especially maritime, My routes are more for the historical descriptions. So far the 20 km routes run OK so will forget the 50 km size for now.
import mathutils
import bge
cont = bge.logic.getCurrentController()
own = cont.owner
#Add master list and kdtree
if 'ML' not in own:
own['Cam']=own.scene.active_camera
ML=[]
for objects is own.scene.objects:
if 'TerrainTile' in objects:
ML.append(objects)
objects.visible =False
size = len(ML)
kd = mathutils.kdtree.KDTree(size)
index=0
for objects in ML:
kd.insert(objects.worldPosition, i)
index+=1
kd.balance()
own['KD']=kd
own['ML']=ML
pos = own['Cam'].worldPosition
# Find points within a radius of the camera
close = 60
far = 65
CL=[]
for (co, index, dist) in kd.find_range(pos, close):
CL.append(index)
if 'GFX' not in own['ML'][index]:
own['ML'][index].visible =True
own['ML'][index]['GFX']=True
for (co, index, dist) in kd.find_range(pos, far):
if index not in CL:
if 'GFX' in own['ML'][index]:
own['ML'][index].visible=False
del own['ML'][index]['GFX']
put this in a object with
always----------(this script)
it may need slight adjustment, but anything past 60 units should go invisible ** (freeing up render time)
any terrain that needs to use this, needs the property ‘TerrainTile’
after we get this working, we should check the profiler to see what else could be slowing you down*
