I haven’t played or looked into BF, I’m speaking of experience on HL2/HL/quake that I’ve worked with in the past. I know few modern shooters feature drop and that means they have to deal with bullet velocities etc. and can’t use raycasting.
The point is that it’s a very expensive feature and simulating bullets requires special attention especially over networking, you can’t get away by using the standard mechanics that you use to simulate a box that can be thrown around. I don’t suggest people try anything as advanced as physics based bullets because as easy as it sounds and it’s very counter-intuitive in the end when you have to tweak and optimize with python to make things playable.
Sry I haven’t got any hand drawn/realistic textures yet beacause first I wanted to find out which texture style would win the poll…D…but I think I’ll use hand-painted textures which won’t be very detailed and add a toon shader…
Yeah, I guess the BF franchise is running on almost brand new software so they can afford to do this however the older engines that you mentioned are more similar to BGE and probably won’t take too well to this in the long run.
You could but its going to be a lot more work! using normal textures is fairly easy but painting them will take a while especially if you are planning on having very complex environments. However if you think this is the best option then feel free to do this
It’s not a matter of engine power. It’s a matter of how much effort you can put into programming, playtesting and optimizing the thing.
If the distances are short (not an open world game) it doesn’t make sense to factor in travel speed because the hits should occur in the same or very next frames anyway. (bullets travel generally between 600-1000 m/s or 10-17 meters in one frame at 60fps.) Conveniently, the long range weapons (such as sniper rifles) fire faster bullets to negate error where the ranges are traditionally greater. This is because essentially weapon design AIMS to do what raycasting does: fire at the target in as straight path and little error as possible.
And let’s add that not even BF or other systems use physics objects as bullets. Rather they process the bullet as series of raycasts that per each section adjusts the raycast direction to simulate gravity and/or wind and checks for any collision in the past or future frame. When it sees an incoming or passed raycast result (another player, ground or wall for example) it functions like traditional raycast bullet. This is essentially an object with specific type of physics simulation (0-volume object travelling on predetermined path detecting hit only along the trajectory).
Hahah good point:D No, I won’t reproduce that in my game. I’ve only rendered it and thought that the scene looks a bit empty so I’ve done a lil edge render…
If you want I could upload a “standard” render of it…
One handed weapon!!! That’s a great idea:D! But then I shoudn’t activate the physics^^
Yes I’ve already made some sketches in the past but they weren’t very useful.:spin:
I agree, normally it’s better to make some sketches before. But today I’ve just started modeling. That worked much better than with earlier attempts with sketches…
as an note to the discussion about bf4 bullet drop over network it ain’t rly that hard to do. this feature where in bf1942 and it came out 2002 if im correctly.
there are an easy way to handle bullet drop in blender over network, as explained here: NOTE 1: this method requires an blend file to coexist or be the server. NOTE 2: using this method can give the server almost all the calculations in the game, making the clients less expensive to run.
step 1:
client fires an bullet and sends an request to the server whit the exact starting location/rotation of the bullet. (need an tcp connection) step 2:
the server receives the request, after syncing everything else the server adds an bullet at the received location and sends back an answer telling every client to add this bullet. (the bullet in the client’s are visual only, and don’t need to be 100% precise.) step 3: as the server continuous to update the player position it is also handling the bullet (in blender this one can be handled as an usual object affected by bullet-physic’s) step 4: the bullet on the server dies or hit an object the server sends an message to the clients telling them that the bullet have died or hit an object. step 5: the clients revive the info about the bullet and do what needs to be done to their visual bullet. no more steps needed, that was easy, wasn’t it?
in order to make this system more accurate for players whit huge ping, an ping compensation system can be used, but i won’t explain that on here.
^I’ve added the 2nd handhold after I already had unwrapped the other parts of the weapon. Now I’m in texture paint mode and see these artifacts. I have already unwrapped these light parts again but that didn’t work…
D…but I think I’ll use hand-painted textures which won’t be very detailed and add a toon shader…
